Hi John,
Bits and pieces below...
On 01/22/2013 07:04 PM, John Leslie wrote:
Joe Touch <touch(_at_)isi(_dot_)edu> 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(_at_)ietf(_dot_)org>,
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(_at_)jlc(_dot_)net>