Thanks for the responses - they were very helpful. On Thu, Apr 15, 2010 at 5:12 AM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> > > > On 4/15/10 12:04 AM, "Evan Gilbert" <uid...@google.com> wrote: > > > - What does it mean to have successive drafts? And if we move an issue to > the > > next draft, what does that practically mean? > > - How does the bill become a law? > > Drafts are numbered but not versioned and they are not reference-able. They > expire after 6 month of publication and cannot be used as normative > references from other specifications. So in practice the latest draft is > simply a representation of where the working group is in terms of progress. > > When the WG is done, it issues a last call to see if anyone in the WG still > has open issues. You can have multiple last calls if a last calls demands > significant changes. > > Once the working group is satisfied with its draft, it goes to an IETF last > call with the same process but with feedback coming from the entire > community and sent back to the WG to be worked out. > > As any given time, the WG does not have to accommodate feedback but should > account for it (reply and explain why). The IETF last call includes > official > review from other areas such as the security area. These reviews must be > addressed (in the same manner though). > > When the document passed through both last calls, it goes to the IESG which > is the IETF governing body consisted of the area directors and the IESG > chair. The IESG votes on the draft to approve or discuss it. There is no > 'No' vote in the IESG (you need 10 yes/abstain votes and no requests to > discuss the draft for approval). > > IESG discussion can take a while until all the area directors are > satisfied. > At that point the document is done and can be referenced, but can take > months to be published as an RFC. The process doesn't end there but the > vast > majority of people treat the RFC as a standard (it is actually just a > proposed standard) and ignore the rest. > > > - What is the expected timing of these drafts? > > Like any standards process it takes as long as it takes. OAuth 1.0 took > about a year without becoming a standard. Once the WG is done, it should > take about 3-6 months for IESG approval and another 3-6 months for RFC > publication. > > BUT - > > Companies can implement the drafts for beta or experimental purposes and > keep them up to date as much as possible. Once the WG draft is done, > companies can ship it with the expectation that it can still change but > with > a general timeline of about 6 months to a year. The primary reason for > changes after WG LC are security requirements. > > As for the WG timing, it is hard to say because we still have a long list > of > open issues. The biggest reasons for WG slowness are busy editors and laid > back chairs. I don't think editorial work is going to slow the WG, but when > it comes to closing issues, we rely on the chairs to make consensus calls > and close open issues when the WG is stuck. > > That said, I think the current draft is close to what OAuth 2.0 should look > like and the list of issues has remained about the same for the past month. > > EHL > > > > > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
