Subject: [newtrk] What we have learned so far about retiring standards

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 16 Dec 2004 18:12:31 -0800

Hi again. I'll start off by saying that I was never terribly fond of 
this work, but the responses that Eliot has gotten so far have been 
pretty instructive. A few things pop out:

- We don't have a clear definition of when something should be retired

- We haven't explained well who this effort is supposed to benefit

- Making something "historic" means very different things to different people

- We don't (can't?) have a clear picture when people will stop 
implementing old protocols

Maybe much of the value we wanted to get from this exercise could be 
gotten from forming a list of RFCs that we say we believe no further 
work will be done on. The presence on the list could be marked in 
rfc-index.txt and rfcxx00.txt.

--Paul Hoffman, Director
--VPN Consortium
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 17 Dec 2004 05:43:11 -0800

> From: Keith Moore [mailto:[email-masked]] 

> 
> > The only thing that is being changed is that the IETF is saying 'the
> > IETF is
> > no longer maintaining these specifications'.
> 
> yes.  yes.  yes.
> 
> whether the specification is being maintained is one or the two or 
> three most significant bits of information that we need to convey.  
> it's also a bit that none of our current classifications convey very 
> well.
> 
> rather than reclassifying specifications periodically, 
> perhaps what we 
> really should be doing is periodically issuing "updates" for those 
> specifications that are actively being maintained.  an update could 
> consist of an applicability statement, errata, clarifications, 
> implementation reports, and implementation notes. 

I agree, but I would also add a mechanism similar to the 'defect report'
mechanism in ANSI. 

One of the main causes of standards bifurcation is when a defect is not
addressed for a very long time and so multiple parties come along and
implement different means of fixing it.

Having a repository of that type of information is a way of avoiding
unnecessary bifurcation, at least there is an easy way to find out what
others have done to address the problem.

	Phill

.