At 07:14 11-01-2013, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'A Fast-Track way to RFC with Running Code'
<draft-farrell-ft-03.txt> as Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2013-02-08. Exceptionally, comments may be
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