Hi SM, I totally agree with your comments and suggestions, the draft SHOULD mention the important clarifications and the answers to SM's questions. This is an important draft and SHUOLD be clear about such important details in sections, why it ignores them without refering to informative procedure items to link things for understanding. How do authors write these drafts are they done with following procedure, AB ++++++++ In Section 1: "Additionally, the experiment will only require issues raised during these three stages to be addressed if they meet the IESG's Discuss criteria." Does this mean that a document does not have to represent consensus? "In contrast, a "-bis" RFC that aims for Proposed Standard or Experimental is likely to be a fine candidate." I read what the document proposes as lowering the barrier of entry for first publication. My preference is to say nothing about "-bis" RFCs (see quoted text). Some of the "-bis" drafts I have come across (note that this is not related to a draft being discussed currently) are not well-written even though there is running code. The running code might be due to author intervention instead of a blind test of the specification. In Section 2: "Implementations developed during the production of an Internet-draft can indicate that a working group has had the opportunity to get early confirmation of its engineering choices." Agreed. In Section 3: "Any Working Group Last Call (WGLC) or Area Director (AD) review (which are routinely done, though not part of the formal [BCP9] process) will run in parallel with the two-week IETF Last Call (IETF-LC) period." I am not suggesting changing the two weeks. It can cause logistical problems. I'll take the risk of trying this experiment. "Only comments that would be "DISCUSS-worthy" according to the IESG Discuss Criteria [DCRIT] need be handled during last call. Other comments can be handled or not, at the authors/editors discretion." See my previous comment about this criteria. In Section 4: "The fast-track process can be used for "bis" RFCs and might well be quite suitable for those." I suggest removing this. "If the timers (IETF LC or the two-weeks after IETF LC for fixing things) co-incide with a major holiday period or IETF meeting then the responsible AD can add a week or two as appropriate." I suggest not using the Fast-Track if it is less than two weeks before or after an IETF meeting. Some people only do IETF work during that period and that results in a spike. I don't think that it is a good idea for this experiment to encourage work during the meeting phase instead of the mailing list. In Section 5: "An AD who wishes to do her review in parallel with Last Call is always free to make that choice." "his" or a gender neutral term. "This memo itself has no impact on appeal processes. However, in considering an appeal that relates to a document that has been fast-track processed, the relevant judge (WG chair, AD, IESG or IAB as appropriate) should consider the requirements posited here." The WG Chair is not a judge in such cases as it would be his/her decision being appealed. Some people are discouraged from bringing work into the IETF because of the long debates (which I likely contributed to). Big companies have an incentive to do work within the IETF. There is a perception in open source circles than there isn't much to gain in having a specification published as a RFC. The young, free and wild will not listen to the fogies. The better approach, in my opinion, is not to act as a gatekeeper or encourage a wall-garden attitude. Regards, -sm