On Fri, Jan 3, 2014 at 12:36 PM, IETF Chair <chair(_at_)ietf(_dot_)org> 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/