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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf