I agree with all of Joel's points, below, and add the following comments.
The fundamental philosophical assumption made by
draft-klensin-iana-reg-policy-00.txt goes too far is that registration
of code points is always a good thing, and it is never bad thing to
reserve a code point in the interests of interoperability and to avoid
problems caused by code point collision. I disagree with this
assumption; as Joel points out, "as much as we claim registration is
not endorsement, it will frequently be seen as endorsement". The
validity of this principle has been accepted by the IETF community and
its general practice, when in RFC 2026 (BCP 9), section 4.2.3, we
allow the suppression of experimental RFC's that are submitted with
the intent to subvert the standards process, by diverting them to the
relevant working group. Why do we allow this, despite our belief that
just because it is an RFC does not give any text any special standing.
While the IETF cognescenti may know this to be true, most people do
not, and automatically give text with the "RFC" label force of a
standard. (Given that most of us still refer to standards via their
RFC number rather than by its STD or BCP number, we help perpetuate
this problem, but that's a debate for another day.)
Beyond the endorsement issue, it can be very valuable to be able to
promote interoperability by trying to elimiate duplicate or
near-duplicate code point registrations. If someone wants to register
a different encoding scheme which is almost --- but not quite ---
identical to base-64 encoding, instead of allowing the registration
and permitting (and perhaps endorsing) this alternate encoding
standard, it can be valuable if someone can explore with the
registrant whether or not the code point is really needed, and whether
there is a technical justification for having this alternate encoding
scheme in the first place.
In the past, my understanding is that the original IANA would perform
such functions, and I think this is a good thing. Converting the IANA
into something that can be implemented using an LDAP server may make
the process more streamlined, but throwing out technical judgement to
help improve some potentially bad ideas seem to be an vey, very
unfortunate side-effect.
I am also very troubled by the provision stating that no registration
could be denied based on scarcity unless a potentially heavyweight
process is initiated to either (a) eliminate the scarcity, or (b)
justify that it cannot be so eliminated. Does this mean that every
single time some kook^H^H^H^H^H, ah...., "enthuastic experimenter"
wants to register a new IP header version, or TOS value, or one of
many, many bit-encoded, restricted fields in the lowest levels of our
protocol stack, we need to create a working group to write an RFC
justifying why expanding the IP version field in the IP header beyond
4 bits would be a Bad Thing?
The argument could be made that "common sense" would not require such
an effort, but the whole point of draft-klensin-iana-reg-policy-00.txt
seems to be to eliminate any ambiguity by spelling out exactly what
should happen, and the way it is currently worded, an implementation
of this registration policy without the application of common sense
could fairly easily result in a DOS attack against the IETF.
- Ted
On Fri, Jul 01, 2005 at 01:03:07AM -0400, Joel M. Halpern wrote:
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf