On 18-mei-2007, at 18:20, Pekka Savola wrote:
IMHO, the key point is to make a decision how to go forward. The
WG chairs have read the consensus as 'deprecate' (mail on Mon, 14
May 2007 16:12:04 -0400).
It is not clear to me whether you're arguing against the result of
that consensus call, or arguing about the lack of clarity in this
draft (in general or specific to section 3).
It's the draft.
Let me start by quoting a dictionary definition of "deprecate":
deprecate |ˈdepriˌkāt| |ˌdɛprəˈkeɪt| |ˌdɛprɪkeɪt|
verb [ trans. ]
1 express disapproval of : [as adj. ] ( deprecating) he sniffed in a
deprecating way.
2 another term for depreciate (sense 2): : he deprecates the value of
children's television.
Second sense of depreciate would be: disparage or belittle (something)
In other words: what this means in a technical context is extremely
unclear. I'm not aware of any IETF document that specifies what
"deprecate" means.
What I envision when deprecating a feature that until that moment has
been a mandatory part of a standard, is that it is no longer a
mandatory part of that standard. Apparently, others have the
interpretation that the feature is now forbidden from being used. I
can see how the chairs observed consensus on the former, but not on
the latter. Also, telling people they are no longer allowed to use
this feature is an exercise in futility: there are tens of millions
of systems out there that implement this feature, it will take very
many years for all these systems to be upgraded or removed from service.
I do not think it's very productive to rathole over argument which
underlying problems are critical, which of them are "security"
versus something else, etc.
Terminology is important.
While it would likely be beneficial to put this on the written
record, getting consensus on these underlying problems would take
much longer than getting consensus for which action to take.
The action follows from the problem, so I'm not sure if this is the
case. But if you know of a way forward that is compatible with the
different views expressed so far, that would certainly be a time saver.
As such, I'd be supportive of having the source routing issues
documented in a separate (non-normative) I-D, but that should not
block advancing this I-D.
One of my objections is that this draft doesn't explain what it does
or why. This is an integral part of what we're trying to do here, we
can't relegate that part to some third order draft. And why the rush?
Implementers are going to do what they're going to do regardless of
the publication date of the resulting RFC. And it's not like we
didn't know the implications of source routing before this.
However, as I think the draft shouldn't spend words in enumerating
the various attacks, it shouldn't discuss the mitigations either.
(Both of these are potential ratholes that we should avoid.)
No, these are central to the issue.
With regard to IPv4, ADs seemed to feel that it should be addressed
in a separate document.
Why? Are we going to have separate documents for IPv4 and IPv6 until
the end of time, even if the issues overlap 80%?
Iljitsch
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
