On Tue, Jan 18, 2011 at 8:58 AM, Spencer Dawkins <spencer@xxxxxxxxxxxxxxxxx> wrote:
Phillip,Lars can speak for himself, but what I THOUGHT he was talking was changing the phrase "unassigned" to something like "reserved for future assignment".That made sense to me...
That would work IF the reason this is happening is that people don't understand that unassigned means reserved for future assignment.
But I rather suspect that the reason that this is happening is that people know full well that there is a process and choose to ignore it because they either can't be bothered to put up with the hassle or don't think that the application will be accepted.
At the moment we do in fact have code points that are reserved as distinct from being 'unassigned' and this is done because it is known that use of that code point will cause a collision. Often because the code point was hijacked.
For example the DNS code points for Apple's Bonjour protocol are reserved rather than assigned.
SRV code points are an even bigger mess because there isn't even a proper registry to enter them in.
I think it is rather more likely that the root cause here goes back to the fact that the old three track standard process has broken down and the criteria for acceptance as a PROPOSED standard are now essentially those for DRAFT.
One of the reasons for having a low bar for initial drafts was that they were necessary to get the required code point assignments.
Lars writes:
>> If five people are experimenting with TCP options and this is not causing collisions, what is the problem?
>Have you read my original email? It *is* going to cause collisions.This type of behavior certainly could cause collisions. But that seems to be a risk that the people who engage in that behavior prefer to take rather than apply for an assignment.
What I am saying here is that people need to be very clear as to what the objectives they are trying to achieve here and make sure that they do not overstep the mark.
If the only priority is to prevent collisions, then it is really easy to avoid problems, just open the registry first come first served.
For many lower level registries that is not an option because there is a real risk of code point exhaustion. That is particularly true with some of the deep down one byte codes. But that is relatively manageable.
What creates real problems and puts those objectives at risk is when control of the registry is seen as a means of ensuring that nobody can deploy proprietary code or encumbered technology or something that someone feels should really be built on the basis of their little pet project so that it gets deployed and used.
There are plenty of cliques who try to engage in that particular type of behavior and far too few people who have the courage to stand up to them and call them out when they do so.
--
Website: http://hallambaker.com/
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf