Re: Use of "unassigned" in IANA registries

[Phillip Hallam-Baker <[e-mail]>]

The first law of the Internet is

   '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 <[e-mail]>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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
Website: http://hallambaker.com/