Date: Fri, 1 Jul 2005 09:36:30 +0300 (EEST)
From: Pekka Savola <pekkas@xxxxxxxxxx>
Message-ID: <Pine.LNX.4.61.0507010917500.20316@xxxxxxxxxx>
| though I can understand the arguments why
| documenting the proposed use could be useful.
I believe it is documented (though I haven't read the documentation
and see no need to do that). What it isn't, is documented as an RFC
(or even an I-D). Whether the documentation is adequate or not
is a reasonable question to ask, and is the question the IESG should
have investigated.
| 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).
And why would you expect that to be the case? Some might be
persuaded by arguments that show a better alternative, a very
few might be persuaded by arguments that say "that's no good"
without suggesting anything better, or at least demonstrating
a problem (in the IETF we tend to tell people who make those kind
of arguments to go away). Others?
| I'd certainly hope that mainstream vendors wouldn't just add
| unregistered/rejected codepoints in their products,
Personally I'd expect that decision to be based upon how many $'s
they expect implementing the option/feature to be able to make for
them, compared to the costs of doing it.
If you believe that vendors have never implemented features in advance
of IETF approval, or even discussion, you're deluding yourself.
(Just consider what happened to the IPv4 TOS byte, and how that
was actually done).
| 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.
Here, I absolutely disagree. Features that start out being restricted
to specific environments have a tendency to escape into wider uses.
In this, I think I am in agreement with those who agree with the IESG's
action, because they have looked at the protocol, don't like what they
see, and are afraid of it (or perhaps something similar in the future)
escaping into the network and doing harm.
I certainly agree that is possible. Where we disagree, is that I cannot
see (as apparently you can't either, though you "hope") that it is
possible to prevent this by refusing parameter registrations.
I prefer to know what is there, to be able to identify it, and to locate
the identifying documentation or responsible person. Others seem to
prefer to pretend that if it isn't registered in the IANA registry, then
it cannot possibly exist (the ostrich syndrome).
| 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
No, that kind of thing has been tried in the past, and it simply does
not work. The "experimental" code points, if they succeed, get
embedded into products, and cease being experimental. And that happens
before anyone realises, and well after the point where it would be
practical to move to a different number.
| 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.
Exactly. This is the point. Do we push them underground, or do
we be honest with ourselves, recognise that this is going to happen,
and at least allow it to happen in a way where the harm to the rest of
us is minimised? We can't stop this, but we can at least observe it.
| 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..
That may be true, but couldn't possibly help here. From what I have
seen, the proponents of the protocol in question are convinced that the
only way for it to work is by using hop by hop options. That is, they
are expecting that everything above the IP layer is going to be (and
must be) encrypted, and they need to send information that the routers
along the path can examine.
That they cannot do by embedding anything in UDP or TCP - then all of
the data would be hidden from the routers.
Or at least, that is my understanding (purely from the e-mail on this
topic that I have read, not all of it public). [I have no idea what
data they need the routers to see, or why.]
| 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,
As above, it would solve the immediate problem, they'd have a code point,
which is all they need, but (if what they're doing works) it isn't going
to stay experimental very long, and the code point is never going to get
altered after it has been used.
| and everyone else could put code in their products to ignore them.
No-one needs to do that (in response to this request). If your IPv6
doesn't already ignore unknown options (or drop the packet, depending
upon the value of the unknown option) it is seriously broken.
There is no case here of something being developed which would cause
everyone (or for that matter, anyone) to be required to upgrade anything
(other than to correct latent bugs that may be exposed).
kre
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf