'You are so not in charge (for all values of you).'
The illusion of control is comforting to some but it is an illusion. At the end of the day the IETF has roughly 2000 people involved. Nobody elected us. We are accountable to no-one.
The Internet has 2 billion users. We do not accept accountability to those users. We cannot even understand what their requirements might be. And even if we did, we may well reject them out of hand.
At certain levels in the protocol stack the use of registries is unavoidable. We have to have compact representations at the IP level. At the application layer, they really don't matter at all.
The illusion of control is comforting, but it comes with costs.
The first cost is the cost of maintaining the registry. Assigning code points requires an administrator, it frequently requires expert review. That incurs time and money.
The second cost is that where there is control, the granting of a code point will inescapably imply approval. I have no problems with the Russian government using GOST but I do have serious problems with the fact that the IETF has assigned code points for GOST.
The third (and in practice minor) cost is the confusion that can arise when folk decide to freeboot themselves a code point. That could cause real problems at the IP layer, but the risk is really rather marginal at all at the application layer. We have remarkably few problems from collisions of file name extensions and we have far more than three characters.
I suggest that the IAB consider a policy for registries that requires all cryptographic and application layer code points to make use of an approved extensible identifier format, with the two approved forms being URIs and ASN.1 OIDs.
Such registries as are then maintained would be strictly limited to tracking identifiers to be used for mandatory and preferred algorithms. Such registries might assign abbreviated identifiers for such algorithms.
The main impact of this would be felt in cryptographic protocols. Instead of having separate private use code spaces being maintained for IPSEC, DNSSEC, TLS and PKIX, each of the protocols would be extended to allow the use of ASN.1 OIDs (where these are not already used) for private code space. It would be up to the developer of the algorithm to assign the OID.
(yes, yes, TLS suites, blah, its fixable)
[There is a small issue to do with URIs in XML based protocols. I think we should collapse that registry into the ASN.1 format by using the OID URN form]
The IETF would then cease considering requests to add code points for non-recommended algorithms for those protocols. The only question that would be considered in IETF space would be whether we want to add a new protocol to the approved list.
The advantage of this approach would be that the 'vanity crypto' problem would largely disappear. Particularly if the IETF/SAAG took the approach that it would only recommend algorithms after it was demonstrated that a very substantial community were either using them or planing to do so and there were clear advantages over existing options.
The same principles would apply across the IETF. Anything that touches an application has to have an extensible registry of OIDs or URIs for code points that affect the application layer.
Removing the barriers to proliferation has the counterintuitive effect of making it harder to establish a new algorithm. There being no barriers, there are more candidates to choose from and the IETF is not available as a forum to promote the proposal. Proposals have to win on their own merits.
Let a hundred flowers bloom and then Darwin can take care from that point on.
This approach would not save people from themselves. But that is a futile effort in an Internet of two billion people where we are not in charge anyway (and neither is anyone else).
On Fri, Jan 14, 2011 at 10:25 AM, Paul Hoffman <paul.hoffman@xxxxxxxx> wrote:
On 1/14/11 12:23 AM, Lars Eggert wrote:
Hi,
On 2011-1-13, at 22:43, Michelle Cotton wrote:
Many believe it makes it very clear to the users of the registry
what is available for assignment. Something we will be rolling out
soon (for those registries with a finite space) will be small
charts showing how much of the registry space is unassigned,
assigned and reserved (utilizing the unassigned entries).
I mentioned in the past that the term "unassigned" to me at least
doesn't make it sufficiently clear that IANA assignment is often
needed before codepoints may be taken into use. We have several cases
(the many different squats on TCP option numbers, for example) were
people pick unassigned codepoints during development and only later
realize that they should have registered them.
If you want to explicitly list unassigned codepoints in the
registries, I'm wondering if we can find a short phrase that makes it
more clear that an IANA action is normally required - maybe
"available for IANA assignment"?
If IANA *doesn't* explicitly list unassigned codepoints in the registries, do you think that would make the problem of unintentional squatting better or worse? I can see it going either way, but you have probably thought about this more than I.
The unintentional squatting problem might be reduced by a note in every registry that says "unassigned code points must be assigned by IANA" or some such wording.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
--
Website: http://hallambaker.com/
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf