It is a hard problem because there are two separate schools of thought in the IETF and very few people recognize that these are in fact in conflict.
The first school of thought holds that the purpose of the IETF is to protect the future of the Internet.
The second school of thought holds that purpose of the IETF is to protect them principle of permissionless innovation that is the heart and soul of the Internet.
The founders of course firmly believed in the second. It is unlikely that they gave the first a second thought, or even a first come to that. At the start, there was nothing to protect.
And here we are 40 years later and the Internet is the fabric of communications across the world. Things have changed, there is indeed something precious that must be protected.
Coming from a country where the founding myth involves the giants Gog and Magog fighting, I have never really seen how you get from that to a justification for any sort of social order. let alone the one we live in today. My people came from northern France 900 years before I was born. I really can't see why slaughtering a lot of peasants in the distant past gives justification to social orders of the present either.
So we can put the opinions of the founders aside and seek to preserve what we have. Which is rather a problem because the IETF has absolutely no plenary authority or power to do anything of the sort.
I have always been on the side of permissionless innovation. That was built into the heart of the Web. anyone could run a Web server, you didn't even need to be a system administrator unless you had to use port 80 for it. And if people weren't paying attention to the radical politics behind the Web then, well all the pundits seemed to have come to the conclusion they thought of them.
Of course, I have worked at the upper levels of the stack since my undergraduate days, the parts of the Internet the architecture is designed to give permissionless innovation to. There is much less scope for innovation, permissionless or otherwise around the narrow waist. There are real and immutable constraints on code points at that level because they aren't making any more 8-bit, 16-bit or 32 bit-positive integers.
But when we get into that interface between network and application and especially with security, problems begin to emerge. People start to argue that we must protect people from themselves and make sure that nobody introduces 'bad' choices. And so we should make sure that there is some sort of bar that must be met before a precious code point is assigned.
It is a nice orderly theory but not one that works in practice because there are three possible outcomes from any binary decision process: Yes, No and no decision at all.
When I asked for code points for the SAML SRV discovery prefixes, there was no process established at the time. After many months of discussion, I did what any responsible person would do in my situation and made them up. I had 50 very experienced and very knowledgeable people writing a specification which required code points be assigned. The problem at issue was the inability to assign any code points rather than the particular choice. So I took my permission from the 'permissionless innovation' wildcard.
And that at the end of the day is the glue that keeps the whole system running because the very worst thing for the Internet would be if there was established any sort of choke point that could be used to control the system at large.
While IANA and ICANN might appear to be control points, they are in J. R. R. Martin's words, swords without a handle. Any attempt to wield them is going to have unpleasant results. While IANA could in theory refuse to grant IPv6 address allocations to Iran or ICANN could in theory drop the Cuba TLD out of the root, neither can happen in practice because the attempt to impose the restriction would lead to the control structures being forked.
I was none too pleased when ICANN claimed control over IANA and the trademark.
So yes, it would be a good thing if the role of IANA were clarified. Not least because as things stand, IANA is really only configured to service IETF as a stakeholder and it would make much better sense if IETF, IEEE, W3C and OASIS all had equal access to IANA as a common numbering authority.
Another change I would like to see is to encourage future application protocols to move away from the hierarchical allocation approach entirely and instead make use of identifiers from a single common registry which only guarantees uniqueness. Consider how Amazon sorts all their stock according to type so that all the electronics are with all the electronics etc: They don't. Amazon famously stores stuff anywhere there is space.
When I was asking for the SAML prefixes, I did not care WHAT the prefix was, only that it was unique to SAML within the context of SRV. But any name that is globally unique is also unique within the context of SRV.
And if I have a globally unique label assigned, I can apply it to multiple purposes - SRV lookup, URN lookup, .well-known lookup, HTTP headers, etc. etc.
The number of 12 character labels from the Latin-1 + digits character set is over 10^18, we can take that as 'unlimited'. So why not just have a common pot for labels that don't have to fit into a 32-bit integer?
The new registry would look something like this
Label Description Reference
saml_pep "SAML Policy Enforcement Point" http://oasis... blah
aes "Symmetric cipher" http://nist.gov/....
In this approach, anyone can register a code point for anything.
OK, maybe a bit too loose for some, let's add a 'purpose' field which takes a label allowing us to group labels with a related function. And those purposes are simply registered like any other label.
That gets us to a point where we can use the uni-registry for anything, no need to create additional registries.
On Fri, Nov 24, 2023 at 12:17 PM tom petch <daedulus@xxxxxxxxxxxxx> 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. 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
