As a general statement, I think this document goes too far.
Several issues occur to me reading it. A sampling follow.
1) As written, the document seems to say that all small allocation spaces
should be "repaired". This does not always follow. Making the IP version
space bigger does not seem a desirable approach to interoperability, for
example.
2) There are issues of appropriateness that are complex, and need to be
considered. For example, there is an ongoing debate in the routing area
as to how much information, and of what kinds, ought to be carried in the
routing protocols. (The problem exists for both BGP and our intra-domain
link state routing protocols.) It would really complicate such a
discussion if the working groups did not have the ability to say "no, there
are uses of these fields which are wrong, and we will not encourage them be
registering them."
3) No matter how much we claim that registration is not endorsement, it
will frequently be seen as endorsement.
4) Allowing arbitrary values in fields which need to be understood for
interoperability can make life very difficult. It turns out that even when
the protocol has planned well for unknown values, the negotiations and
exchanges can get very tricky. And the more extensive the set of options,
the harder it gets.
5) There are sometimes subtleties about who is appropriate to provide the
definitions for some values. Particularly if the meaning relates to
proprietary activities. Just having clear documentation is not always
sufficient.
6) For some purposes it is important that the document actually be right,
not just clear. To use a historical case, there was a request for
registration of a number space at one time which was accompanied by I-Ds,
etc. It was however mathematical falsehood. It would not
work. Registering it would have been a disservice to the community. In
that particular case, the problem was clear. But other cases may not be so
clear.
6') We are usually fairly careful about registering cryptographic
algorithms, and we try to make sure that our experts think the algorithms
make sense. This document would seem to do away with such checks. (I
believe this is an example of one way that a document may be extant, and
readable, but subtly harmful or false.)
7) There are clearly spaces / applications / domains where people can and
should be encouraged to experiment. But not all spaces have that
property. We have enough trouble with junk in spaces like DNS without
agreeing to register any type code / meaning that someone wants to write up.
Yours,
Joel M. Halpern
At 12:11 AM 7/1/2005, Spencer Dawkins wrote:
If I may plead for a moment of silence ...
There is an Internet Draft that is intended to give the community a chance
to provide comments on what the IETF vision of option registration might
be - or, might not be.
If we could discuss this draft, and say things like "I agree", "I
disagree", "goes too far", "doesn't go far enough", it seems to me that we
might actually be able to come closer to closure in this thread (and its
predecessors), one way or the other.
That URL, again, is
http://www.ietf.org/internet-drafts/draft-klensin-iana-reg-policy-00.txt.
And I apologize for having nothing whatsoever to say about spamops,
killfiles, or steering.
Thanks,
Spencer
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf