Re: S stands for Steering [Re: Should the IESG rule or not?]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]