See Standard 58 (ftp://ftp.rfc-editor.org/in-notes/std/std58.txt) which defines deprecate (as it is used for IETF MIBs at least) numerous times.
More general (and less pejorative) definitions than the one you offer can be found in many places... Thanks! -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] > Sent: Friday, May 18, 2007 12:44 PM > To: Pekka Savola > Cc: IETF IPv6 Mailing List > Subject: Re: problems with draft-ietf-ipv6-deprecate-rh0-00.txt > > 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 > -------------------------------------------------------------------- >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
