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

--On Thursday, 30 January, 2003 15:45 -0500 Thomas Narten 
<narten(_at_)us(_dot_)ibm(_dot_)com> wrote:
> 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.
That was the conclusion of the WG.  I don't exactly remember the 
reasoning, but it might have had something to do with a 
conviction that we wanted the barrier to be fairly high and 
serious and that even Experimental was an escape clause.
> > 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.
Yes, but part of the discussion in Atlanta and on the 
problem-statement list is whether the type of review you are 
describing is an abuse of IESG authority and discretion. 
RFC2026, at least as I read it, permits IESG to hold up an 
informational or experimental document that was submitted to the 
RFC Editor _only_ to prevent or annotate end-runs and things 
that would be harmful to the infrastructure.  "Not harmful" is a 
much lower threshold than "IETF Consensus".   So, if you expect 
IESG review to "hold up" anything that does not originate from 
within the IETF, or to comment on any such documents, you had 
best seek a procedural authorization for doing so.  I can't 
speak for the community, but my impression is that tolerance for 
IESG "holding things up" --and I am astonished that you are 
willing to use those words-- is rapidly diminishing.
> 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).
Yes, but see above.

> > > 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.
Ok.  Then we need to add to the oral tradition that, if a WG 
wants serious review, they should not use the term "IETF 
Consensus", but should replicate the 1869 text, with or without 
inclusion of informational documents as they think appropriate.
> > 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).
Ok, modulo the observations above.

  john