Thanks for the comments, some replies inline. On Fri, Sep 17, 2010 at 1:39 PM, SM <sm@xxxxxxxxxxxx> wrote: > Hi Ted, > At 16:25 16-09-10, Ted Hardie wrote: >> >> The attached draft is part of the discussion Russ started up >> with draft-housley-two-maturity-levels. It is compatible with, >> but does not require a reduction in maturity levels. If you > > The -00 draft passes ID-nits. There is a mistake in the XML template (see > Requirements) used to generate the draft. This problem is apparent in other > drafts as well. > Thanks for letting me know. > In Section 2: > > "In practice, IETF document processing has evolved to a model which > can be described as "objection based processing". > > I'll only consider WG submissions for simplicity and I have reduced the > "processing" to two stages, the Working Group Last Call and the IETF Last > Call. The Working Group Last Call generally does not use the "lazy > consensus" approach. In other words, there should be support for a draft > for its adoption as a Working Group item and for it to get through the > working group stage. This is a good point. It is really late-stage processing that works mostly by resolving issues (especially the IESG processing, but to a lesser extent the Last Call processing). I will update the description in the next version. It can be argued that the IETF Last Call, in general, > tends to be "lazy consensus" as there aren't that many, if any, comments > about WG drafts at that stage. I don't see the model as one of "objection > based processing" because to the first stage. > > "The IETF Last Call is, in practice, a way for the larger community > to object to a document or elements within it." > > The IETF Last Call is about getting cross-area review. There is a subtle > difference between that and "a way for the larger community to object". The > latter presumes that someone within the IETF community which is not in the > working group has the time and energy to review the draft. > Any review that produces useful input is generally accepted by the document authors. But only objections really change the processing from that point on, but creating a requirement to resolve them before moving on. In other words, the document processing state machine can only change here if an objection is lodged. > "It is also relatively clear that the energy to object can always > be found in the IETF, even when the energy to sponsor or shepherd > a document is absent." > > "Consensus by exhaustion" works well within the IETF. It can be used to > drive away other IETF participants. > Noted. > I'll open a parenthesis to comment about shepherding. One of the questions > asked is: > > "Does the Document Shepherd have any concerns about the depth > or breadth of the reviews that have been performed?" > > If the shepherd is chosen by the author of the draft, it is highly unlikely > that the answer will be a "yes". > Agreed. But the shepherding and initial document and shepherding the resolution of an objection are a bit different. Perhaps a different term is needed to make this clear. What I propose is that after an objection is lodged to advancement, that the IESG will determine whether it is a valid objection, based on input from the objector and the work of the shepherd. > In Section 3: > > "All documents which are published as Proposed Standard RFCs shall be > entered in queue for advancement to Draft Standard, with automatic > advancement to take place two years from the issue date of the RFC." > > The requirement for an interoperability report is not mentioned here. The > proposal does not specify what happens if an interoperability report is not > submitted. > This proposal does not require an interoperablity report. > I would have suggested the following: > > All documents which are published as Proposed Standard RFCs and which > have not advanced to Draft Standard, within two years from the issue > date of the RFC, will be moved to Historic status. > > The onus is on the proponents of the RFC to submit an interoperability > report. There should be an option for the author to ask for Informational > instead of Historic if the specification is still in use. > I think this proposal is closer to Keith's thinking than mine. My personal belief is that neither the carrot nor the stick has been particularly effective in eliciting interoperability reports and efforts to move to draft. Given that, we can rest on a single-stage system in the common case or use something else to signal to the larger community how mature a standard is. This proposal uses a time-and-consensus call approach. If you believe that there is energy to use the interoperability-test based current system, then there is no need for the the change this proposes > "If no document shepherd comes forward, the objections are > automatically sustained and the document remains at Proposed > Standard." > > That would keep some documents at Proposed Standard for a long time. One > question that comes to mind is whether it is the responsibility of the IETF > to find a shepherd or if it is for the author to do so. This is similar to > the problem of how authors can get reviews for their draft. I'll elaborate > on that even though it is not relevant to the discussion. > I think if no community member is interested in resolving an objection, then the document is not needed. I understand the issue that the author may be an interested party and may offer to shepherd. That could set up an unfortunate author-vs-object dynamic. The IESG still judges, however, and can determine whether the objection should be sustained. > A person writes a draft. He or she does not know how to get people to > review the draft. As the person has not reviewed other drafts before, he or > she might find it difficult to convince someone to write a review. As the > saying goes, I scratch your back and you scratch mine. In plain English, if > you review other people's drafts, it would be easier for you to get people > to review your draft. If you don't have the time or energy to do so and > everybody does that, the mechanics won't work. > > In Section 4: > > "Those who are entering errata for a published RFC should indicate > whether they believe the issue raised is sufficient to block > advancement." > > That turns an errata into a DISCUSS. I don't think that the errata > mechanism should be used like that as it is going to create more problems > than it will solve. If errata becomes a discussion forum, it will be more > work for the Area Directors. Do you think the presence of serious errata would currently prevent an AD from taking an existing document through the advancement process, even if implementation reports were received? I do, but this may be a question of interpreting "serious". > > "Any individual who has been banned from the IETF main list may not > post an objection, and repeated frivolous objections should be > considered grounds for removal of posting rights." > > If this draft moves forward, that sentence will probably be removed. I am > not going to comment on that point for now but I understand it. > > In Section 8: > > "If the broader Internet community is judging protocol maturity based on > standards level, there is some risk that changing the mechanism by > which documents advance along the standards track may require that > judgement to change." > > If the broader Internet community is judging protocol maturity based on the > RFC brand, there is nothing the IETF can do about it. Some people view > "Proposed Standard" as being a level above "Draft Standard". Some authors > do not even read BCP 78 even though they state compliance in their draft. > > There is an presumption of mutually assured destruction in the current > discussion model. Those that have nothing to lose have nothing to fear. > Noted, but this still leaves the final decision in the hands of the IESG. The upshot, though, is that any mechanism which shifts most drafts up the ladder will increase the overall workload. I've tried to lower the friction for the "easy" cases and distribute it for all cases. But that doesn't create new energy. If too much of the new energy required comes from the IESG, this will obviously have other bad effects. Further input on how to better distribute the load is welcome. regards, Ted > Regards, > -sm > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf