On Fri, 1 Jul 2005, Scott W Brim wrote:
You can add me to the "satisfied" column. The IESG is asked to take positions and to lead (despite what a few think). That's risky -- no matter what they do they get criticism from somewhere. Maybe they didn't *phrase* the announcement perfectly, but the decision is correct. Something like this must have a serious, long-term IETF review. We need to take the overall design of the Internet into account and not just be administrators.
FWIW, I haven't said anything on the thread but I'm largely satisfied with the IESG action, though I can understand the arguments why documenting the proposed use could be useful.
However, I believe there is a significant difference between "proposed use" and "actual use". I'm hoping that most of the people who come asking for these code points, but don't get one, will change their designs (so a code point is not needed) or engage in a dialogue (instead just picking a code point and getting it implemented). I'd certainly hope that mainstream vendors wouldn't just add unregistered/rejected codepoints in their products, and if the use is restricted to a minor vendor or a very specific environment, I doubt many care too much one way or the other.
If we want to enable any kind of protocol to get any kind of code point (instead of just stealing one), I'd think it might make sense to split a few codepoints from the registries to be allocated using a more relaxed process (RFC3692/BCP82 may or may not be a partial solution here), so that the vendors could more easily just ignore those options.
However, I think an important benefit of a sufficiently strict allocation procedure is that those people who have a genuine desire to design a protocol that's at least halfway sensible need to initiate the community in a technical dialogue. In the process maybe the community is swayed, or the protocol designer sees that a different approach may be much better. We can always hope so.
No matter what we do, there are always going to be people who try to push their own protocols, not caring to hear any feedback or input, and the process (for the most cherished IANA resources) should be strict enough to limit the damage those could inflict.
Or maybe there is a need for a short document explaining that if you want to build FOO protocol, it might make good sense to design it using TCP/UDP and FCFS assignments, instead of using more scarce or more tightly controlled resources, especially if you have a tight market DL and/or don't want to engage in a technical dialogue in the IETF..
In the particular case of hop-by-hop options, maybe the best approach could be to assign a couple of experimental code points per RFC3692. If folks want to deploy (in small scale) or test their ideas, they could always use those codepoints, and everyone else could put code in their products to ignore them.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf