Date: Thu, 30 Jun 2005 21:12:07 -0400
From: Jeffrey Hutzelman <jhutz@xxxxxxx>
Message-ID: <D28F9326E3312065397163F7@xxxxxxxxxxxxxxxxxxxxx>
| Note that I would consider it entirely reasonable for the IESG to say that
| something "conflicts with work in the IETF" on the grounds that its
| deployment would break the Internet, since preserving the stability of the
| Internet is a fundamental part of _all_ IETF work.
I cannot agree with that. Preserving the stability of the internet is
the responsibility of the internet operators. There's nothing the IETF
can do, one way or the other, to affect that. There may be times when
the internet operators seek assistance in developing protocols to assist
with particular problems, but that doesn't make solving them the IETF's
responsibility.
When the IETF develops protocols, they generally need to work on the
internet, and if the protocol is going to (or even could) prevent the
internet from working, then the protocol itself isn't going to be
very effective (like designing a truck, that you want to run over
regular streets, but which destroys the streets as it passes over
them - it is very quickly useless).
If some packet, or data, causes harm to the network, the network operators
should be making sure that packet doesn't enter their network (for self
survival purposes). This is whether or not the packet in question is
being used by a blessed IETF protocol, or something different.
That is, I have no problem whatever if all of the network operators were
to install filters to prevent any packets containing this proposed new
option from ever entering their networks. Of course, to do that, they
are going to have to know how to recognise the option. A listing in the
IANA registry would sure make that simpler, wouldn't it?
| I don't think that is the case here. The IESG is not blocking the
| registration; it is simply declining to allow it without community review
| and consensus.
And they also said they wouldn't be allowing that review, because they
have pre-decided that it would not succeed, but would be a waste of
resources. The IESG is unquestionably blocking the registration.
| But, I also think the IESG's advice is at least partly accurate. Reviewing
| something of this size and complexity in the IETF is likely to take quite
| some time. It would likely result in changes, some incompatible, and some
| parts might be scrapped altogether. I'm not in a position to evaluate the
| argument that it would probably not gain community consensus, and I'm
| beginning to believe the IESG should not have said that -- not because of
| whether it's true or not, and not because of the resulting controversy, but
| because of the chilling effect created.
Now you are starting (just beginning...) to see some of the reasons that
I complained about the IESG's response initially. Not because the code
point should actually be registered (I have no idea on that, though I
certainly lean towards registering most things) nor because I care about
the protocol one way or the other, but because the approach that they took
was so fundamentally wrong.
kre
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf