On Sat, Oct 30, 2010 at 1:17 AM, John C Klensin <john-ietf@xxxxxxx> wrote: <snip> > However, a change to the handling of documents that are > candidates for Proposed Standard is ultimately in the hands of > the IESG. In principle, they could announce tomorrow that any > document submitted for processing after IETF 79 would be > evaluated against the criteria in 2026 and no others other than > reasonable document clarity. If the IESG has the will --and > whatever community backing is needed-- to do that, then the > "two-step" document is not needed. If the IESG does not have > that will and backing, then community of the "two-step" document > would merely leave us --as far as this issue/problem is > concerned-- with one more set of rules we aren't following. > John, Thanks for your thoughts on this. While I agree that the IESG could theoretically make the change you describe above, I don't think they can practically do so. Along with the increasing IESG review, there has been an increasing sense that Proposed Standards may be winnowed but likely will not be changed in core mechanism unless there is significant breakage. Given the weight of the "Installed base" argument, however wrong it may be, I doubt the IESG would be comfortable reverting to 2026 without some label changes either in Proposed or the follow-on levels. They need something beyond an IESG note to hang their collective hats on. A lot of the education on the point "RFC != IETF Standards track document" may actual tie our hands here, because its the first level at which we've told folks in external SDOs that they can count on. The current functional case is, in my opinion: Subsets of the drafts adopted by working group (those that are functionally complete, bascially) are the new Proposed Standards Proposed Standards are now close to what Draft once was, with significant comfort that this is what will be there for a long time. Draft is used only when Proposed Standards include something that needs cutting or an external driver requires advancement Standard is used only when an external driver requires advancement. An issue (again, not the *the* issue) is that only those deeply involved in a WG can tell which drafts have gone into the subset. That may hinder cross-area review (since potential reviewers can't tell which ones are important enough to do). When I re-write the advance mechanics draft, I will propose something along the following lines: 1) A WG snapshot-like status achieved after agreement by the working group and a posting by the WG chair to IETF-announce notifying the wider community and inviting review (presumably by review teams). Any document may reference this level for any level of maturity; it is not just functionally archival, but a recognized state. 2) A status called "IETF Standard" that is reached after the current (real) procedures for Proposed. 3) A status called "Internet Standard" reached when an "IETF Standard" has spent at least 3 years as an "IETF Standard" without any errata, objections, or the creation of a -bis or -ter effort. A new document may be issued to correct errata without requiring re-spinning in "IETF Standard" grade. This is either a 3-stage document model or a 1-stage, depending on whether you are counting labels or trips through the IESG. This does not solve all the problems I put forward; it does not magically breathe energy into any working group, for example, nor does it handle the pulse-of-activity timing. But it does solve the marketing problem and recognize the role of the subset of agreed I-Ds in the real world. For one document, that's probably the best we can do. For what it is worth, I don't think this is very different from what is Russ's document, other than my being more willing to fiddle with status names and him being less willing to do so. Possibly this is because I really do read his statement of restoring "Proposed" to the core 2026 values at face value. Were that in place, we could realistically expect WGs to throw documents over the IESG wall periodically as "snapshots" and get much the same place. I personally suspect, however, that we need *some* rejiggering of the labels at this point, just to highlight the rules in place at the time something was approved. regards, Ted PS. On re-labeling things en-masse to make them fit the new scheme, I don't really want to, because I can't see how to make it work without a massive effort by someone. Changing the names in actual use may help that, as an SDO can say "Proposed Standard or IETF Standard" for its reference guidelines. > So, if we are serious about changing (or reverting) those > criteria, then let the IESG issue a statement about the new > rules, schedule, and any transition plan. Let's see if such a > statement is successfully appealed by someone (I'd hope, given > the concerns on this list about the problem, that wouldn't > happen). And then let's see if we can actually do it. > > There is lots of time to change the written procedures if such > an effort works, even experimentally. After all, we've been out > of synch with 2026 for 14 years now and it hasn't shut us down. > > best, > john > > p.s. I also believe that, if part of the intent of the > "two-step" document is to restore that bar, it is _very_ hard to > deduce that from the document itself. I'd feel better about the > document if that were more clear. But the document is really > not the issue, the strategy is. At least IMO. > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf