--On Wednesday, July 3, 2019 21:52 -0400 Keith Moore
<moore@xxxxxxxxxxxxxxxxxxxx> wrote:
>...
> But of course that's not stating it as strongly as I
> remembered, and the problem of deploying implementations based
> on Proposed Standard existed even before that. I remember
> a flap about telnet implementations circa 1992 in which
> implementations of a certain option didn't interoperate - one
> vendor followed the PS text and all of the others implemented
> it in the opposite way, and I heard a lot of people saying
> "they shouldn't have deployed at Proposed".
Keith,
I don't know if it was the same incident or a different one, but
there was an incident around then that I remember vividly (for
reasons that will become clear). In that case, an implementer
implemented and deployed to a PS (or maybe an I-D) and then the
IETF changed its mind and revised the specification. That
first vendor complained loudly and bitterly. I had just come
onto the IESG and Phill Gross told me that my first job was to
go explain to that vendor that they could complain all they
liked but they weren't going to get much sympathy for jumping
the gun and deploying something that wasn't ready and that
turned out to be a bad idea. Not my idea of fun, then or now.
For better or worse, the three-level idea in 2026 and elsewhere
has always been aspirational -- a good idea in theory but rare
in practice. You will recall that the aspiration was high
enough at one stage that documents were expected to be
automatically obsoleted if not advanced. That didn't work.
The October 2011 decision to drop to two levels (RFC 6410) was
expected to improve the fraction of documents that advanced and
our image be dropping things to two levels. AFAICT, that didn't
do much either: my entirely subjective impression is that, after
a fairly brief burst of activity, the fraction of documents
advanced out of Proposed Standard has remained rather close to
constant and very low: by my very rough count, we have published
around a dozen documents as Internet Standards since late 2011,
plus a few more documents that were advanced in place.
The problem is that there has rarely been energy to go back and
do the cleanup work. In some cases, there have been specific
reasons to not do it.
We also have a mechanism for saying "you really need to
implement this", "that is optional", and "that other is is not
ready for prime time except under unusual circumstances". We
don't use that either.
So I agree that things were once clear had we followed our own
rules. However, we have never consistently done that.
And there are multiple problems with more types of labels in
addition to the question of who gets to assign them. If a WG
does it, we face a particularly difficult version of a problem
that probably should be challenged more frequently: approval of
documents after IETF Last Call on the say-so of WGs because
there are few if any substantive reviews during Last Call and
hence no real evidence of informed community consensus. We
would also certainly discover that neat categories don't work
and we need textual descriptions in at least some cases, a
requirement that brings us back in the direction of the NEWTRK
work, the core of which the IESG disliked enough to refuse to
put out for Last Call.
So maybe we are ready for some new ideas. But I suggest that,
the more subtle our categories and distinctions, the easier it
will get for implementing organizations to advertise their
implementations as conforming to IETF-approved standards and the
more incentive they will have to do so.
best,
john
