Standards Classification and Reality Problem Statement (was Re: Not a problem statement [ was Re: Killing old/slow groups - transition thinking)

[Kurt D. Zeilenga]

Part of the classification problem is that the IESG has not
done expired-in-grade standard track RFCs reviews.  (Or, minimally,
they have communicated their decisions as required by RFC 2026.)

   When a standards-track specification has not reached the Internet    
   Standard level but has remained at the same maturity level for     
   twenty-four (24) months, and every twelve (12) months thereafter     
   until the status is changed, the IESG shall review the viability of
   the standardization effort responsible for that specification and the
   usefulness of the technology. Following each such review, the IESG  
   shall approve termination or continuation of the development effort,
   at the same time the IESG shall decide to maintain the specification
   at the same maturity level or to move it to Historic status.  This   
   decision shall be communicated to the IETF by electronic mail to the 
   IETF Announce mailing list to allow the Internet community an       
   opportunity to comment. This provision is not intended to threaten a
   legitimate and active Working Group effort, but rather to provide an
   administrative mechanism for terminating a moribund effort.

I suspect that if such reviews were actually done, not only would
many documents be moved to Historic, but we'd see viable
standardization efforts spring up to move the suitable documents
forward.

Kurt


At 08:35 AM 12/16/2002, James Kempf wrote:
>Fred,
>
>
>> At 02:45 PM 12/13/2002 -0800, James Kempf wrote:
>> >The issue here isn't the perception
>> >that Informational documents are Standards, but rather that a WG ID will
>> >inevitably become the standard, without substantial modification in any
>> >form of
>> >its basic design and contents.
>>
>> Hmm.
>>
>> Is this a matter of frustration/concern? I thought that the reason we met
>> in working groups was to develop consensus documents that would support
>> interoperable implementation, which is to say "to become the standard".
>>
>> If that's not the expectation, what in the world are we spending all this
>> time and aggravation trying to do?
>>
>>
>
>Let's back up a little.
>
>The original issue was the relevance of the current PS/DS/S classifications.
>Someone noted that there are very few DSs and even fewer Ss. Why? And what
>relevance do these classifications have for the needs of IETF's customers today,
>as opposed to when they were originally proposed?
>
>What I was trying to point out is that WG ID has taken on much the same function
>as PS when it was originally proposed. Once a document becomes a WG ID, there is
>little or no change in the basic design, it is essentially impossible to get it
>removed, and for all intents and purposes it has become a de facto standard,
>regardless of what the template text says and regardless of what the IETF rules
>are. The advantage of using the WG ID in this form over PS is that the text can
>be changed as problems are found with implementation, whereas trying to change
>the text in a PS is impossible without reving the RFC number, which is today a
>long and heavyweight process. Being able to change the WG ID facilitates
>incremental design, and ultimately interoperability.
>
>There is no requirement for interoperability when something becomes PS. And very
>few standards become DS. So we are left without any formal requirement for
>interoperability when making something a standard by the criteria that most IETF
>customers believe that it should be.
>
>The overall problem is that the world has changed since the original
>classifications were done, and, at the risk of once again getting told that this
>is a problem statement list and not for solutions,  I think we ought to
>recognize the role that a WG ID has as, in effect, a de facto standard, and
>require interoperable implementations for PS. Whether we keep DS and S is
>unimportant, but we need to recognize reality.
>
>            jak