Subject: Re: [newtrk] new cruft draft due out today or tomorrow

From: [email-masked] (scott bradner)
Date: Wed, 15 Sep 2004 13:23:01 -0400 (EDT)

Harald sed:
> Actually there has never been a requirement for an RFC to be published when 
> something is made Historic; this is an invention based on practice, and was 
> never part of RFC 2026. In my opinion, it is a bad practice, and should be 
> abandoned. 

it is correct that such douments are not required by our standards
process but that is only part of the story

I see no reason to publish a doument to say that some standard was moved
to Historic (or Informational) because the technology it described 
is just not used or because a new version of the technology has been
approved. This has been done in the past (RFC 3109, RFC 3166 and RFC
3167 are examples) but I do not see enough of a reason to do this in the
future to overcome the opinion of people like Harald that its a
pointless waste of time and effort.

But, if there is a specifc reason that the IETF feels a technology
SHOULD NOT be used it seems to be a real good idea to document that in a
RFC.  Examples include RIPv1 (RFC 1923) and LDAPv1 (RFC 3494). i.e.,
if we know of a reason to 'just say no' it does not help anyone if we do
not write that reason down.  

Scott

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 15 Sep 2004 22:10:41 +0200

> not write that reason down.

I agree. But I think writing those documents needs to be something the 
Cruft Committee is NOT charged with doing - because otherwise it will have 
so much "fun" drafting those that they never get around to dealing with the 
obvious cases. Separation of function!

Individual committee members are, of course, free to take information 
collected by the committee and go push such a document themselves!

                       Harald

.