--On Thursday, 30 January, 2003 15:45 -0500 Thomas Narten <narten@us.ibm.com> wrote:
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.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.
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.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).
Yes, but see above.
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.> 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).
Ok, modulo the observations above. john