--On Wednesday, 01 October, 2008 17:44 -0700 Dave CROCKER
<dhc2@xxxxxxxxxxxx> wrote:
>
>
> John C Klensin wrote:
>> Opinions (or an IESG decision) welcome, as would be an
>> indication of whether I really need to write an I-D that
>> modifies 2026 to resolve this question and whether the IESG
>> would be prepared to process such an I-D.
>
> First question is: Why have any delay at all? I presume the
> answer has to do with broader community exposure -- review and
> maybe experience, although 4 months is not enough for serious
> experience.
>
> If indeed that reason is right, it seems that distribution
> doesn't happen until the RFC is officially announced. Until
> that moment, the document is subject to some change. So
> that's when broader public exposure starts.
>
> I'd rather argue for "as soon as the working group approves
> it", particularly for going from Draft to Full, but I can't
> think of logic that makes it compelling.
Dave,
"No delay requirement at all" would, at the discretion of the
WG, essentially collapse the three-stage process into one, plus
bureaucracy. In principle, a WG (or individual submitter) could
generate a document, claim interoperability and wide deployment,
and get the IESG to vote on it three times, perhaps in the same
week.
As the author in recent (and not-so-recent) years of proposals
that would essentially replace the categorical three-step system
with descriptions of the community's confidence in a document
and that would require the IESG to move older documents directly
to Full Standard if independent implementations,
interoperability, and wide deployment and use could be
demonstrated, I think you can assume that I view changes that
would streamline things with some sympathy.
However, every single simplification proposal introduced since
2026 was published has had something in common with all the
others: inability to achieve sufficient community consensus that
the IESG would approve and process the change.
Whatever one might like in a world more optimized to our
individual desires (and yours and mine might or might not
agree), I believe it is useful to get a specific answer to a
question that 2026 leaves open, without opening the debate about
what 2026 should say in areas where it is, for better or worse,
perfectly clear. In this particular case, I also have a very
specific issue with a pair of documents that represent
specifications whose broad deployment and utility are, I
believe, incontestable and vague text in 2026 that can be
interpreted to make a calendar quarter's difference or more.
Scott Bradner has reminded me that the IESG has discussed and
answered the question (in favor of the Protocol Action
announcement date) several times, but never written the answer
down.
I hope it is possible to get IESG and the community to agree on
a definitive answer to that question and move forward without
having to queue it behind another attempt to explore the
no-consensus ratholes of reforming the standards process or
rewriting 2026. The way to do that, IMO, is to fix the starting
point definition (which probably requires fixing the description
of publication announcements) and treat changes to the waiting
period or other changes to the basics of the standards process
as a given for this purpose and separate issues for other ones.
Put differently, do you believe that it is useful to get this
"starting point" glitch fixed or do you feel a need to block it
until we can reopen and resolve a large collection of issues
about which we have never been able to establish consensus in
the past? I think the correct answer to that question is
obvious, YMMD of course.
john
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf