Re: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFC with Running Code) to Experimental RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: 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
>  		 	   		  
> 


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]