Review for Historic

Harald Tveit Alvestrand harald@alvestrand.no
Tue, 17 Dec 2002 13:22:09 +0100


actually if you search the Web carefully, you might find this URL:

http://www.apps.ietf.org/maybe-historic.html

Last modified: Sun Nov 28 09:59:00 2000 - I wrote the original version some 
years before that, I think.
After a while, I decided to find different windmills to tilt at; there's no 
shortage of them, and there's not enough energy to do the legwork AND fight 
the people who say "don't bother".

               Harald

--On mandag, desember 16, 2002 09:09:01 -0800 "Kurt D. Zeilenga" 
<Kurt@OpenLDAP.org> wrote:

> 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
>
>