Perhaps things have settled down sufficiently for me to express an opinion...
I am not an IANA weenie. But I think registries should register things.
We have a decent amount of running code (for example, http://www1.ietf.org/mail-archive/web/ietf/current/msg35953.html) that says our attempts to limit what gets deployed by limiting what gets registered don't work reliably.
Exactly. FWIW, media types, email header field names, and charsets are all good examples of other ways things can go wrong. Now, the vast majority of the registries we have are ones which for whatever reason aren't terribly popular: Additions to the registry are rare and so is use of unregistered values. (Take a look at the list of IANA registries and you'll find dozens of these.) We may like to think of these as registry success stories, but getting scaling considerations "right" is easy when no scaling is needed. Then there are some where only a few values are registered but several other values are in common use. A good example of one of these was the protocol name registry used in email WITH fields: For the longest time only "SMTP" was standardized but a small set of other values were frequently used. RFC 3865 changed that, but writing this sort of RFC and getting it through the process turns out to be surprisingly hard, so much so that most registries with this particular problem never get dealt with. (An nearby example of one that hasn't been cleaned up are email VIA fields.) Then there are the registries where there's an escape hatch for private values. Sometimes this is sufficient to prevent use of supposed-to-be-registered values and sometimes it doesn't. For example, most private SMTP extensions - and there are a bunch of them - have elected to the X-prefix naming convention marking them as private use. OTOH, email header fields that don't begin with "X-" abound that from context are clearly carrying private-use information. (This problem is so prevalent that there was no consensus to continue having the "X-" convention in RFC 2822.) Or consider media types, where the initial registration procedures were overly onerous and where for whatever reason people didn't like seeing "X-", so literally hunderds of unregistered values came into widespread use, use which continues to this day. The bottom line is that despite being informed by many years of experience we aren't nearly as good at this stuff as we seem to think we are.
...
What I would like to see is a clear distinction between IANA as a registry and the IETF as a protocol standards organization.
Agreed. This would help a lot.
...
I also note that one of the many "wireless is special" things I've seen in the past decade was the WAP Interim Naming Authority (WINA), now resurfacing as the Open Mobility Naming Authority (OMNA) (see http://www.openmobilealliance.org/tech/omna/index.htm). There are probably other pseudo-IANAs I don't know about. Our choke-hold on the parameters the world uses isn't quite as tight as it needs to be in order for us to use IANA as an enforecment tool.
Well, we like to talk about how the network we have helped create routes around problems at many levels, but we seem to be unable to comprehend that sometimes we're the ones that are perceived as being the problem. It is hardly surprising given the very mixed results we've had with our own registries that other registries have sprung up. And since I have no real expectation that we're going to clean up our act as a result of this or any other discussion, this sort of thing is bound to continue and even accelerate. Ned _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf