> > Nothing prevents the document from being submitted directly to > > the RFC Editor, for publication as a non-IETF document. > That is the avenue I would prefer, but it raises another issue > (which I think would fall into the category Eliot referred to as > <a corner in the process>). As Sam points out, the actual use > of this as a protocol requires IANA registration of parameters > and current procedures for TLS extensions and many other things > require IETF consensus for such registrations and hence for > publication of any document that specifies, or requests IANA > registration of, such parameters. To be clear, in this particular case, is there no room for getting assignments out of a vendor-specific case? That escape clause is in many name spaces... I am all-too-aware that there are corner cases that come up where the actual IANA considerations rules don't really handle a situation well. Even when WGs/authors do to right good IANA Considerations, the reality is that its hard to think of all things in advance. Consequently, draft-narten-iana-considerations-rfc2434bis-06.txt added a new rule (not in 2434) designed to cover such cases: 5.3. Overriding Registration Procedures Since RFC 2434 was published, experience has shown that the documented IANA considerations for individual protocols do not always adequately cover the reality on the ground. For example, many older routing protocols do not have documented, detailed IANA considerations. In addition, documented IANA considerations are sometimes found to be too stringent to allow even working group documents (for which there is strong consensus) to obtain code points from IANA in advance of actual RFC publication. In other cases, the documented procedures are unclear or neglected to cover all the cases. In order to allow assignments in individual cases where there is strong IETF consensus that an allocation should go forward, but the documented procedures do not support such an assignment, the IESG is granted authority to approve assignments in such cases. The intention is not to overrule properly documented procedures, or to obviate the need for protocols to properly document their IANA Considerations. Instead, the intention is to permit assignments in individual cases where it is obvious that the assignment should just be made, but updating the IANA process just to assign a particular code point is viewed as too heavy a burden. In general, the IETF would like to see deficient IANA registration procedures for a namespace revised through the IETF standards process, but not at the cost of unreasonable delay for needed assignments. If the IESG has had to take the action in this section, it is a strong indicator that the IANA registration procedures should be updated, possibly in parallel with ongoing protocol work. If the above text were in effect today, would it be sufficient to cover the situation at issue here? (Now would be an excellent time to consider updates/clarifications to the above text.) Thomas _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf