Hi John, Bits and pieces below... On 01/22/2013 07:04 PM, John Leslie wrote: > Joe Touch <touch@xxxxxxx> wrote: >> On 1/11/2013 8:21 AM, Adrian Farrel wrote: >>> >>> The proposed experiment calls on the IETF Secretariat to take specific >>> actions under certain circumstances in corner cases of the experiment. > > Specifically: > ] > ] 8. If at any point in the fast-track process the responsbile AD does > ] not act in a timely fashion then the IESG Secretary should ensure > ] that the draft enters IESG evaluation and is scheduled for the > ] the soonest IESG telechat that is more than one week after the > ] end of the two-week post-IETF LC period. That is, if the > ] responsible AD does not act, then the default action applies > ] which is that the draft enters IESG evaluation and is placed on > ] the earliest IESG telechat. > > I honestly don't know who or what the "IESG Secretary" might be: > several of us have assumed this is a typo, and "Secretariat" was > intended. > > (There is one mention of "Secretariat" in the draft, but it speaks > of what WG Chairs must do, not what the Secretariat should do.) Fair enough. I think the terms effectively mean the same set of folks though. > >> This is a silly idea. > > Assuming that Joe refers to the item quoted above, I find myself > forced to agree with Joe (which is scary ;^)... > > (There is, BTW, an email address <iesg-secretary@xxxxxxxx>, which > feeds into an automated ticket-generation system. I have been asked > not to respond to it because it tends to get overloaded.) > > If we actually wanted the Secretariat to take the actions listed > above, they would need an automated tool to "discover" the inaction > of the AD involved. Perhaps ultimately, were this to be a part of our permanent process. > From the paragraph above, I frankly have no idea > how to program such a tool. "AD didn't hit button to move forward or backward"? Absent a tool, my guess is a WG chair would complain and some other AD would tell 'em to talk to their AD or ask the secretariat to push the button. This is very much a corner case. > "Enters IESG evaluation" is a simple state variable, mostly harmless. > "Scheduled" for an IESG telechat is a little vague. Usually this means > creating a "ballot" where each IESG member can enter a "position," but > there are other ways to get on the agenda. > > Who gets to decide whether this paragraph calls upon the Secretariat > to create that ballot? > > What time-limit applies between adding the item to the agenda and > the actual start of the telechat? I have seen items appear _after_ > the "FINAL Agenda" is posted the afternoon before (and have done my > best to discourage such a practice). I'm not seeing the vagueness there sorry. > >> First, running code should already be considered as part of the context >> of review. > > Considered how? > >> Second, running code is not correlated to correctness, appropriateness, >> or safety. See Linux for numerous examples. > > Exactly! Evaluating the correlation of running code to the printed > standard-to-be is a long-winded process. > >> Third, running code doesn't mean the doc is sufficient that multiple >> parties can generate interoperable instances. It's merely the sound of >> one hand clapping ;-) > > Here I disagree with Joe (familiar territory!) -- the existence of > one open-source implementation decidely helps other implementors to > produce interoperable instances. > > (Alas, at the same time it tends to hide ambiguities of the spec.) > >> Finally, NOTHING should circumvent the multi-tiered review process. >> That process helps reduce the burden on the community at large via >> the presumption that smaller groups with more context have already >> reviewed proposals before they get to the broader community. > > This "multi-tiered review process" is somewhat mythical. To the > extent it actually exists, I believe it benefits us; but accomplishing > it in limited time is iffy at best. > >> This is a bad idea even as an experiment. > > I'd like to call folks' attention to one paragraph in the Introduction: > ] > ] In summary, this experiment collapses three stages of the publication > ] process to run concurrently: working group last call, AD review, and > ] IETF last call. Additionally, the experiment will only require > ] issues raised during these three stages to be addressed if they meet > ] the IESG's Discuss criteria. The former is not formally a process > ] change, although it is a change to the normal conventions. The > ] latter is a process change and requires this experiment to be run > ] under the auspices of [RFC3933]. > > All the other verbiage aside, _this_ is the point of the experiment: > to remove any implied requirement to respond to LastCall comments that > don't meet (current?) IESG Discuss criteria. (There is, fortunately, > a normative reference to these, but being a web-page, one wonders if > it will be entirely stable...) Stable enough for an experiment I think. That might be something that would need attention should we want to adopt this permanently after the experiment I agree. > > It is unreasonable to expect every commenter to read that web-page; > and I can testify that IESG members sometimes disagree on how it should > be interpreted. In practice, I believe this change will mean that the > effort now spent responding to comments from respected IETFers will > tend to be replaced by justifying why no response is needed. :^( I don't think that'll happen much. Maybe a little though. > To me, it seems unfortunate we should even be "experimenting" with > paying less attention to comments from the more-experienced IETFers. > The existence of "running code" doesn't make evaluation simpler. :^( Yet, we have found these criteria valuable in IESG review, right? I think they could be equally valuable here too. > > I wonder if we might do better to encourage the "Experimental" > status for potential standards _with_ running code, and distribute > the evaluation during the period of experiment (rather than try to > squeeze "enough" evaluation into IETF-wide LastCall). > > ==== > Quoting from RFC 2026: > ] > ] A Proposed Standard specification is generally stable, has resolved > ] known design choices, is believed to be well-understood, has received > ] significant community review, and appears to enjoy enough community > ] interest to be considered valuable... > > Will this still be true under this proposed experiment? I think it'll be no less true than today for documents as they arrive at the start of IESG review. > > ] A Proposed Standard should have no known technical omissions with > ] respect to the requirements placed upon it. However, the IESG may > ] waive this requirement in order to allow a specification to advance > ] to the Proposed Standard state when it is considered to be useful and > ] necessary (and timely) even with known technical omissions. > > I would feel less nervous about this experiment were it to include > a specific IESG action to waive the "no known technical omissions" > clause. But IESG evaluation is unchanged. Cheers, S. > > -- > John Leslie <john@xxxxxxx> >