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@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? 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 > >