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.
I very much agree with this principle. Although maybe that's a topic for
another blog article or discussion… my article was mostly in the context of
managing registries when we have already decided that it is one of those rare
cases where a registry is needed, and have already decided what the rules and
form of the registry is.
The wonderful thing about the Internet is indeed that most things do not need
central control or registry.
A couple of responses below for the registry design question:
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.
I think I agree with this problem statement.
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.
I think we are trying. Can you be more specific about areas where there is lack
of consistency? We can try to improve rules about specific IANA registries,
provide more guidance to experts, etc. if we are not performing well enough in
some area.
One important change is that every future application protocol proposal
should be required to have an effectively unlimited code space for assignment.
Agree.
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.
Here I am not so sure. Registries for adding specific crypto algorithms are not
merely number allocations; they go with specifications and code that actually
runs, say, AES on IPsec or AES on TLS. It is not entirely clear to me that
crypto across different protocols and use cases should proceed in lock step.
And even if it were useful, it is a difficult change to make retroactively,
when the code points in different protocols started out differently.
But maybe I'm misunderstanding your suggestion.
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.
This is interesting, and I could see a use case for it.
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.
This I agree with.
Jari