|
+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: abdussalambaryun@xxxxxxxxx > To: sm@xxxxxxxxxxxx > CC: ietf@xxxxxxxx; iesg@xxxxxxxx > > 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 |