Re: "IETF consensus" in IANA considerations [was Re: Last Call: CR-LDP

--On Wednesday, 29 January, 2003 20:20 -0500 Thomas Narten 
<narten(_at_)us(_dot_)ibm(_dot_)com> wrote:
> ...
> As one of the authors of RFC 2434 "Guidelines for Writing an
> IANA Considerations Section in RFCs", I have long regretted
> defining the term "IETF Consensus" as it is in that document.
> 2434 says:
>
> >       IETF Consensus - New values are assigned through the
> >       IETF consensus process. Specifically, new assignments
> >            are made via RFCs approved by the IESG. Typically,
> >            the IESG will seek input on prospective
> >            assignments from appropriate persons (e.g., a
> >            relevant Working Group if one exists).
> >
> >            Examples: SMTP extensions [SMTP-EXT], BGP
> >            Subsequent Address Family Identifiers [BGP4-EXT].
> The intent of the above wording was to provide a way for
> documents to request that IANA only assign code points when
> there exists a document that gets published as an RFC. The
> wording above specifically does not say "Standards Track" RFC
> and was intented to include informational and experimental
> documents, whether from a WG or not. There is an alternate
> definition - "Standards Action" - that can be cited if IANA
> assignments are only to be made for Standards Track documents.
>
> I think intent of the above definition is fine. But naming the
> term "IETF Consensus" is obviously problematical and
> confusing, as there are many Info and Experimental RFCs for
> which there is nothing close to IETF consensus on, and no one
> would claim so.
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").  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.
> 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.  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.
IMnvHO, ambiguous procedures documents that confuse the readers 
and the community, and that then encourage or require IESG to 
make ad hoc decisions about how to interpret them, get us into 
far more trouble than issuing RFC-quality clarifications or 
replacements.  Even when the older documents have been around 
much longer than four years.
regards,
  john