On 20 Jul 2011, at 01:41, Joel Jaeggli wrote: On Jul 19, 2011, at 2:34 PM, Doug Barton wrote: >> On 07/19/2011 14:01, Sabahattin Gucukoglu wrote: >>> Clearly, the view that making something historic when it's in active use is offensive. No standards body could seek to stand behind their specifications, or to give the impression of doing so, with such a position. > > That's a fairly odd position to take, if we do something which turns out to be a bad idea, should we stand behind it regardless of the validity of the criticism? No. But if it's in active use, we have something of an obligation to the users. The fact that it's in use is a fairly clear indication, regardless of technical quality (the review process being meant as an aid to identifying the more obvious problems before publication) that it is or can be made to be useful. That's an argument in favour. I don't dispute that protocols can turn out to be harmful, and there's a good vs bad benefit analysis to be made for lots of different reasons, but as has already been said before, the historic label is an *extremely* blunt instrument that is almost always reserved for specifications that have actually come to rest, following the logical English definition of "Historic" or "Historical". Better for the community to be informed about the good and bad of protocols with troublesome aspects. > The number of drafts, I've seen over the course of the last decade and a half with the title "foo considered harmful" woulkd tend to indicate otherwise. > >> Define "active use." > > If in fact no-one were using it there would be little point in engaging in the activity. Right, precisely. If the call weren't made, or it were made but happily ignored by everyone, I think we can take it as red that nobody minds too much. > rfc 5095 and 4966 were not created to address issues that were due to protocols being dead to the world... Well, FWIW, NAT-PT is still implemented and in use, most recently for evil purposes. But once again, the designation means that the protocol has reached the end of its useful service life; there is no further use that can't be better served with our newer, shinier standards. That is something we explicitly indicate, so implementers can get on and implement the better solution. And in every case, we have "Applicability statements" or "Reasons to move" documents, so the community understands. Cheers, Sabahattin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf