Hiya,
On 01/11/2013 07:33 PM, SM wrote:
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(_at_)ietf(_dot_)org 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?
You mean rough consensus of the IETF I guess? Good question.
First, WG rough consensus is formally unaffected. As is IESG
review. And if IETF LC comments are received that do meet the
IESG discuss criteria then those should be handled as now.
So I guess we're left with cases where there's a lack of
rough consensus during IETF LC but where the meat of the
disagreement is something that doesn't qualify for an IESG
discuss ballot.
I'd say that'd be quite likely to allow the responsible AD
to say that there had been so much debate during IETF LC that
this experiment ought not be used.
So, I don't think this experiment has any major effect
there really but maybe has a subtle one.
I'll be interested in seeing if this happens if we do the
experiment.
"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.
I don't get what you mean. Can you explain? (I get that you don't want
to mention -bis cases, but I don't get why.)
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.
Not a bad idea. Something like "fast-track must be started at least
one month (longer?) before an IETF meeting starts" ?
I guess the only problem I'd have with that is that for an experiment
that'd run for one year, that takes out about 4 months (3 meetings
and the year-end holidays) which is a lot.
If we extended the experiment to 18 months duration I'd have no
problem with something like that though. Or with leaving it as-is.
Let's see if we get any other opinions.
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.
I'll leave that to the rfc editor. He'll fix it:-)
"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.
Can be. If a WG participant says "the decision you made on that
draft is broken: I appeal" then they first send that to the WG
chair.
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.
I don't see any text change being suggested there. Correct me if
I'm wrong.
Cheers,
S.
Regards,
-sm