Tom,
On 25-Nov-23 06:16, tom petch wrote:
Every so often I see a post about IANA and what they do and what they do not.
The IETF does not always do well with processes, but there are a fair number of RFC and IESG statements to provide guidance to those contributing to the IETF, about WG, IESG, I-D, document streams. The RFC Editor seems to me to do an excellent job of guiding authors down the road of producing an RFC. IANA seems a black hole (swamp?) by comparison.
Several times I have seen questions asked about the underlying principles for creating registries; a recent one was looking for an RFC, a IESG note, anything to help. My take is there is no such thing. Once you are on the road, into the technical details, then RFC8126 tells us what to do. I see nothing to help you get to that point.
I'm puzzled by what is puzzling you. If you're designing a protocol that needs magic numbers defined, such that every implementor uses the same magic numbers to achieve interoperability, then it quickly becomes apparent that you need a public registry. Occasionally you'll see a comment in a WG thread like "Shouldn't there be an IANA registry for that?", and then the right thing happens.
The issue also arises when discussing protocol extensions:
https://www.rfc-editor.org/rfc/rfc4775.html#section-3.2
https://www.rfc-editor.org/rfc/rfc6709.html#section-3.6
In this instance a passing ISE provided guidance, that ISE documents cannot create a registry which calls for IETF actions; that I have seen him do before, but whether there is anything to back that up, whether or not it is true, I know not.
It is certainly true. RFC8726.
The IANA website likewise is good at telling you what valid values there are for e.g. 'RTSP/1.0 Headers' but the big picture is missing; what is and is not the function of IANA, what they can and cannot do.
They do what the IETF requests them to do, for any registry created by the IETF. The very big picture is in RFC2860 and the details are in a supplemental agreement. I'm not sure if this is the latest version: https://www.icann.org/en/system/files/files/ietf-iana-agreement-2020-15jan20-en.pdf
Likewise, a recent email pointed out that the encoding was wrong in a registry but how do you get that fixed. That I think I know but it did make me wonder how much I18N there is in IANA; can I create a registry giving the Kanji equivalent of 'To:', 'From:', 'BCC:' and the like? (If not who says not?)
That is entirely the IETF's choice. RFC8126 applies.
This is not an IETF issue IMHO, probably an IAB one, but this list is where I expect many of those affected might be interested in the issue. The IETF is dependent on IANA- take IANA away and much of the IETF will fail - the IETF would have to create its own registry function.
That's why we have RFC2860 and the supplemental agreement.
Brian
Tom Petch
