John,
Thomas, not to be splitting hairs, but the intent --at least in
SMTP-EXT (STD10/RFC1869), which was cited as an example-- was
somewhat more than simple publication as an RFC (or, in your
words, "a document that gets published as an RFC").
Agreed, now that I have gone and looked at RFC 1869. Some relevant
wording from 1869 would seem to be:
Any keyword values presented in the EHLO response that do not begin
with "X" must correspond to a standard, standards-track, or IESG-
approved experimental SMTP service extension registered with IANA. A
conforming server must not offer non "X" prefixed keyword values that
are not described in a registered extension.
By my read, it would seem that informational documents can't be used
to assign such code points.
While, clearly, "standards track" was not intended, we did intend
that the IESG make a formal decision that the request was consistent
with community consensus (as well as having a published document).
We didn't specify what steps the IESG would go through in reaching
that conclusion, but, other than the 2026 requirement for a Last
Call for standards-track documents, nothing else does either. The
simple ability to convince the RFC Editor to publish an
informational or experimental document was not intended to be
sufficient, even with IESG agreement that the document wasn't likely
to be severely harmful.
I should clarify a bit, as I also agree that just convincing the RFC
editor to publish is not good enough. When the IESG reviews non-WG
documents, ADs always have the chance to review them to see if there
is some reason to comment or otherwise hold up publication. In the
case of something like an SMTP extension, I can't imagine that the
document would get approved without a relevant AD first consulting
with some mail knowledgable folk first. The details of how that are
done are not written down, but in practice broken proposals would not
get approval without some discussion first.
In practice, "IETF Consensus" (as defined in 2434) means that
procedurally the IESG has to sign off on a document before IANA
assigns code points for it. And for something that relates to an
existing IETF protocol, we almost always check with some knowledgable
folk as to whether the document conflicts with that protocol or
otherwise is problematical before approving. So, I suspect that in
fact, the review you are saying is supposed to be happening would
happen in practice in this case (and in other similar cases).
So, let's be clear that in the context of most of the
discussion on this thread, folks seem to be applying their own
definition of what "IETF Consensus" means when in fact the
2434 definition is what should be used, as is cited in the
relevant IANA considerations section.
I don't know what can be done a this point to change the
terminology in 2434. It's been in use for some 4 years now...
I don't see that there is a problem. Especially to the extent
that you can argue that 2434 modifies or clarifies the
procedures that 1869 calls for, I can imagine nothing that would
prevent revising and reissuing 2434 if you think clarification
is needed.
I don't claim 2434 updates 1869; in fact, I'd argue otherwise. 1869
was cited as a specific example, but you've pointed out that it is an
incorrect example.
Or, if it were preferred, one could modify the I-D
IESG procedures document to "update" 2434 and specify exactly
what the IESG does in those situations going forward.
I think the wording in 2434 is quite clear. When someone says "IETF
Consensus, as defined in [RFC 2434]" (which is the type of language I
like to see in documents because it is VERY clear), IANA doesn't
assign code points until the document is approved for publication as
an RFC. As the IESG approval is one of those steps, IESG has a chance
to review. If folks actually want a different criteria, there are a
number of other choices to choose from in 2434, or they could write a
very specific one (subject to it being something IANA can actually
deal with).
Thomas