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.) > 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. From the paragraph above, I frankly have no idea how to program such a tool. "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). > 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...) 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. :^( 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. :^( 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? ] 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. -- John Leslie <john@xxxxxxx>