On Tue, Jan 18, 2011 at 8:58 AM, Spencer Dawkins
<spencer(_at_)wonderhamster(_dot_)org>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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf