Hi Bernard, I'm sorry, I have no idea what it is that you agree with. Can you elaborate?
Thanks, S. On 01/12/2013 10:47 PM, Bernard Aboba wrote: > +1 > > [IAB Chair hat off]. > >> Date: Fri, 11 Jan 2013 22:25:38 +0100 >> Subject: Re: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFC >> with Running Code) to Experimental RFC >> From: abdussalambar...@gmail.com >> To: s...@resistor.net >> CC: ietf@ietf.org; i...@ietf.org >> >> 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 > >
