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@xxxxxxxx > >https://www1.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf