+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
