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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf