> 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