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