On Fri, Jan 3, 2014 at 12:36 PM, IETF Chair <chair@xxxxxxxx> wrote:
In this article I wanted to highlight an important but often hidden part in the IETF ecosystem: Internet Assigned Numbers Authority (IANA). What is IANA, how does it work, how is it related to the IETF, and how has it evolved over time? How will it evolve in the future, and how can you participate in the discussion?
I think that the article needs to go back to some basic principles.
The whole point of the end-to-end architecture was that it enabled innovation and diversity. In particular it was possible to add applications to the Internet without going to some central authority to ask permission. The IETF is not in the business of deciding how people use the Internet except to the extent that doing so may harm others, it is only in the business of setting standards that enable interoperability.
So when we look at the role of IANA, there are different concerns for different protocol layers. The concerns at the IP layer are different to the concerns of DNS which are in turn different to those of applications.
At the IP layer compact representation is vital and code points are a very scarce resource by necessity. Allocation has to be carefully considered because they potentially affect the routers at the core of the Internet which are very difficult to change.
The DNS is an interesting case because the number of code points is generous but finite. Less than 1% of code points are assigned.
At the application layer we have the curious situation that port allocations are essentially exhausted so we use ports 80 and 443 for everything. But in most cases the general rule should be that application protocols should be designed so that code points are not a constrained resource and the primary purpose of assignment should be to prevent ambiguity arising and to provide as much documentation as is possible.
We have learned to our cost that X-Headers don't work. Telling people to go experiment in a sandbox and then come to the IETF when the protocol is ready and get issued a real code point has not worked. It guarantees we end up with multiple code points.
The status quo for most registries is that they are permissive but there is a large amount of difference in the criteria and there are experts involved doing reviews for some systems but not others. There is a general lack of consistency. A standards organization should look for consistency.
One important change is that every future application protocol proposal should be required to have an effectively unlimited code space for assignment. Another is that application protocols should be required to reuse code points from common registries rather than define their own.
At the moment we have separate crypto registries for TLS, IPSEC, PEM, PKIX and XML Digital Signature. The JOSE folk want to create another. There should be a policy that tells people from the start that there will be no new crypto registries.
Fixed length numeric assignment codes as TLS and IPSEC use should be verboten and the text based registries merged into one common registry of labels for all new assignments. So the SHA-3-256 text label would be the basis for the URI form used by XML signature. The per-protocol registries should then be closed to new registrations so that all crypto labels are assigned from one registry on a first-come first-served basis.
One change that should be made is to separate out the assignment of code points from the endorsement of code points. Assigning a code point should mean no more than it won't be assigned for a different purpose. It should not imply any form of endorsement.
Endorsement may be limited to an expert reviewer noting that a particular document or institution should be considered the authoritative source of the specification explaining a code point or it could be an IETF standards action.
The IAB should be tasked with ways to reduce the number of separate registries required. Reuse of an existing registry is almost always better than defining a new one.
Coinsider the SMTP protocol. Even though the URI form for SMTP is actually mailto:, it is obvious that the SMTP URI scheme could not possibly be assigned to a different protocol without major confusion at the very least. The same argument goes for .well-known.
Rather than have three separate registries and attempt to avoid conclusions it would be better to have one registry for text labels so that registration of a label automatically reserves the corresponding .well-known, URI and SRV code points in one go.
If we took this to an extreme there would be only one registry of text labels and the entries would describe the use(s) for which the label has been assigned. If a label is assigned as an application protocol identifier then it can't be a content type or an encryption algorithm. But it is probably just sufficient to prune down the registries somewhat.
Finally, we need to change the assignment process for OIDs because it is really hard to get a bunch of companies to agree on a draft if the OID assignment is off one corporate arc. Rather than assigning arcs in the open registration arc only to companies, they should be assigned to projects.
So in my Privacy Hardened scheme, I am going to need to define a new ASN.1 structure (puke) and some extension OIDs. In the current scheme I would have to cut them off the Comodo arc (which makes getting buy in from Symantec, etc. etc. harder) or my personal arc (Default Deny Security). Both of which are likely to end up having all the entries renamed if the proposal becomes an IETF working group. If instead I get a new arc for the project, I can then hand over change control over the arc along with the rest of the protocol if it is accepted by the IETF (or the same for W3C or OASIS). If the project is not taken up then I keep control.
The objective of all these reforms is to emphasize that the role of the IANA is to facilitate innovation, avoid unintentional collisions and not to enforce control. It is not possible to prevent a use of the Internet by withholding an assignment.
Website: http://hallambaker.com/