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. 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. 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. 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?) 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. Tom Petch
