Process - Check the Impl. Draft process and report

[Nat Sakimura]

No description provided.

[Nat Sakimura]

Relevant sections in the procedure are table-1 and section 5.

Section 5 is as follows:

5 Specification Approval.

5.1 General.

There are three stages of an OpenID Specification – draft, Implementers Draft, and Final Specification. An OpenID Specification begins as a “draft” and retains this status until approved as an Implementers Draft. An Implementers Draft may be further revised, and any revised Implementers Draft is deemed a “draft” until it is approved as a new Implementers Draft. The most recent Implementers Draft may be approved as a Final Specification. There is no specific timeframe under which a draft must become an Implementers Draft or an Implementers Draft must become a Final Specification, although the WG should make reasonable efforts to conform to any posted schedule of deliverables on its Webpage. Only after it is ratified to be a Final Specification, the specification may use the title “OpenID”.

5.2 Review.

The applicable period to review a proposed Implementers’ Draft or proposed Errata will be no shorter than 45 days, and the applicable period to review a proposed Final Specification will be no shorter than 60 days. The applicable WG Editor(s) will post the draft for review by Contributors to the applicable WG, and by the Board, and promptly notify these Contributors and the Board that the draft is available for review. Contributors to the applicable WG will make reasonable efforts to review the draft, Implementers Draft, or Errata during the review period and provide any critical comments or objections , with sufficient specificity for other Contributors to respond and, if required, to facilitate resolution. The Board will also consider the draft at its next meeting, or within 30 days of such notice (whichever is earlier). If, by Supermajority vote, the Board determines that approval of the proposed Implementer’s Draft, Final Specification, or Errata will create untenable legal liability for OIDF or the Board, or that the proposed Implementer’s Draft, Final Specification, or Errata is outside the WG’s Scope, the Board will report this finding back to the WG, and the WG will revise the applicable draft before any vote of the OIDF membership occurs. If the Board takes no action under this §5.2, the decisions of the applicable WG and of the OIDF membership will proceed according to §§5.3 and 5.5.

5.3 WG Decision.

The decision to recommend approval of a draft as an Implementers Draft, to recommend approval of the then-current Implementers Draft as a Final Specification, or to recommend adoption of Errata should be based on consensus. If the WG cannot reach consensus, then the decision may be made by formal vote. The WG Editor(s) will notify the WG of a determination that consensus has been reached or of a call for (and results of) a formal vote. The notice and vote will be in accordance with the specifications in Table 1, but the pre-vote notice required may be concurrent with the last 14 days of the draft review period. Any Implementers Draft, Final Specification, or Errata for which the WG recommends approval will include a list of Contributors who participated in its development.

5.4 Rejection;

Resubmission. If there is not consensus to recommend approval of an Implementers Draft, Final Specification, or Errata, and the proposed Implementers Draft, Final Specification, or Errata is not recommended for approval by vote, then the WG will continue to revise the draft to resolve objections received during the review period. The Editor(s) may (if they deem it appropriate) notify the WG and the Board of a new review, which should be limited in scope to objections received during the immediately prior review and measures taken to resolve such objections.

5.5 Final Approval.

If there is consensus of, or a formal vote by, a WG to recommend approval of an Implementers Draft, Final Specification, or Errata, the applicable WG Editor(s) will notify the OIDF secretary, who will then post the applicable draft for review by the OIDF membership for a period of at least 45 days and notify the OIDF membership of the WG recommendation to approve and of the proposed dates on which the review period will end and the vote of the OIDF membership to accept or reject the WG recommendation will occur. The notice and vote will be in accordance with the specifications in Table 1, but the pre-vote notice may be concurrent with the last 14 days of the draft review period.

5.6 Changes.

No Substantive Change may be made to a Final Specification; any Substantive Change will require review and approval of a successor version of the applicable Final Specification according to these Processes. Any changes to an Implementers Draft should be made in a subsequent Implementers Draft or in an applicable Final Specification. A WG may also (but no more than once every six months) recommend Errata to a Final Specification to the OIDF membership for approval and promulgation (and any such recommendation will promptly be submitted to a vote of the OIDF membership, in accordance with the voting procedures in §3). “Errata” means a set of changes (or proposed changes) to an existing, published Final Specification, created for the sole purpose of correcting features (and not adding or removing features) due to a lack of clarity or an error in the Final Specification, and made available either as a list of changes or as a “redline” markup to the Final Specification. “Substantive Change” means any change to a Specification that is not Errata.

[Nat Sakimura]

For intra wg decision, we are taking consensus route as was in the Connect WG charter, we will not be required to do the vote. Here is the requirement for the consensus:

3.3 Consensus.

Consensus is a core WG value. To promote consensus, Editors should encourage consideration and resolution of all legitimate comments of Contributors. All Intra-WG decisions will optimally be made by determining consensus, without formal vote. Editor(s) will assess consensus without a formal vote and, when a proposal is pending, may interpret silence of those who have received proper notice (or who are present) as assent. Consensus does not imply unanimity, although there should be substantial support for consensus decisions. For Intra-WG, Core Decisions, consensus should reasonably reflect the opinion of a Supermajority of Contributors to the applicable WG, after reasonable inquiry by the Editors. For Intra-WG, Non-Core Decisions, consensus should reflect the opinion of a majority of Contributors actually expressing an opinion. . If a decision cannot be made by consensus, the WG should defer decision until consensus can be reached. If deferral would prejudice a WG’s work, however, the Editor(s) may call a formal vote in accordance with §3.4.

[Nat Sakimura]

So, the step would be like this:

1. In the regular WG meeting, Editors should discuss whether there is a consensus per section 5.3 and 3.3.
2. If yes, then Editors send the notice of start of the review period per section 5.2 to the contributors. It will be 45 days. The notice MUST have the start and end dates of the period.
3. On the same day, the secretary should send the notice of the OIDF membership review. The OIDF membership review period is 45 days. The notice should be sent multiple times, including to the legal contacts. It also MUST state the start and end dates.
4. The contributors review it. The board should review within 30 days to evaluate if it poses risk to OIDF, and if by super majority vote the OIDF board decides that the risk is too big, it should notify the WG so that the revision can be made.
5. Provided that there was no change required, at the latest on the 31st day of the review period, notice of voting should be sent and put prominently on the OIDF web site.
6. Simple Majority vote with quorum of 20% of the membership.
7. 7 days voting period. Proxy is allowed in which case the person who gives proxy must indicate his OpenID identifier and designate the proxy's OpenID Identifier.