Subject: [newtrk] Re: I-D ACTION:draft-alvestrand-newtrk-historical-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Apr 2004 10:21:28 +0200

The underlying idea is good. Unfortunately I think it's premature until we
decide whether to change the number of steps in the standards track, except for
the simple case of reclassifying as Historic.

A couple of specific comments:

> 2. New Decommissioning Procedure
...
>    o  For each standard in question, the Commission sends out a message
>       to the IETF list and the lists deemed relevant, asking for
>       implementation experience and active usage.

Surely that must be the IETF-Announce list? And surely it should be
"and the lists and individuals deemed relevant"?

> 3. Individual Decommissioning Procedure
...
>   o  Maintenance on the standards track (per 2026)

Is a transition to BCP allowed if appropriate?

...
>    o  Reclassification as Informational.(XXX Do we require a new
>       classification?)

I don't see why. If it has value, it's information, so it's Informational.

...
>    on the standards track. (XXX DRAFT NOTE: Cannot a small community
>    continue to use a Historic standard, such as, oh, SNMPv1?)

Of course. That's why we have Historic and the never-change, never-delete
policy for RFCs.

   Brian

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-alvestrand-newtrk-historical-00.txt
.
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: Mon, 26 Apr 2004 10:51:21 -0700

(note - I'm replying as me, I don't hold the edit token....)

--On 19. april 2004 10:21 +0200 Brian E Carpenter <[email-masked]> 
wrote:

> decide whether to change the number of steps in the standards track,
> except for the simple case of reclassifying as Historic.

I'm not sure I understand what part you're thinking of......
The only significant "new" part that is there is about reclassifying as 
Informational, I think - is that what you're thinking of?

> "and the lists and individuals deemed relevant"?

I was wondering about the reasonableness of adding a new large number of 
messages to ietf-announce just after removing the draft announcements. But 
it does have more subscribers. Good point.

> Is a transition to BCP allowed if appropriate?

If maintenance happens, anything allowed while maintaining standards is 
appropriate. I don't think the Commission should do this - just as the 
Commission should not do the maintenance work.

.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Apr 2004 09:55:07 +0200

Harald,

> Informational, I think - is that what you're thinking of?

No. I was thinking that if (which is one proposal) we reduce the number
of Standards track states to one, then the formal difference between PS, DS
and S will vanish, and there will be no issue with any of the existing
PS and DS documents unless we want to make them Historic.

  Brian

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 27 Apr 2004 07:26:16 -0700

--On 27. april 2004 09:55 +0200 Brian E Carpenter <[email-masked]> 
wrote:

>> > The underlying idea is good. Unfortunately I think it's premature
>> > until we decide whether to change the number of steps in the standards
>> > track, except for the simple case of reclassifying as Historic.
>>
> of Standards track states to one, then the formal difference between PS,
> DS and S will vanish, and there will be no issue with any of the existing

Yes - the idea of aging out documents in a single state is a bit different 
than aging out "works in progress".
I believe most other SDOs have some "review and remove" concept, though - 
wasn't the standard for 7-track magtapes de-standardized a few years ago?

I'll admit to having some double motive for this proposal, though - if we 
as a community cannot come to consensus on such a relatively lightweight 
process for doing what 2026 said we would do, and actually execute that 
process, we have (IMHO) proved by experiment that the community is 
incapable of supporting a "review and reclassify" function, and can safely 
assume that no such function can rationally be part of the new tracks we're 
designing.

So based on that .... I argue that we should run this proposal now, 
supporting the 2026 definition of the standards track - and what we learn 
will be extremely valuable input for the NEWTRK discussions.

So I don't think we should wait.

                  Harald

.

---

From: John C Klensin <[email-masked]>
Date: Tue, 27 Apr 2004 16:24:41 -0400

--On Tuesday, 27 April, 2004 07:26 -0700 Harald Tveit Alvestrand 
<[email-masked]> wrote:

>...
> Yes - the idea of aging out documents in a single state is a
> bit different than aging out "works in progress".
> I believe most other SDOs have some "review and remove"
> concept, though - wasn't the standard for 7-track magtapes
> de-standardized a few years ago?

The historical norm in those organizations has been to have a 
regular review cycle, typically around five years, after which a 
document must be explicitly reaffirmed (requiring much the same 
balloting process as approving it in the first place), revised, 
or withdrawn.  The default action in the absence of someone 
doing something is, at least formally, to withdraw, and 
documents really did time out and disappear.  Note that this 
applies to full standards, not works in progress of any variety. 
If applied directly to our model, it would require putting basic 
standards like IP, TCP, UDP, etc., back on the table for review 
and revision at regular intervals.   Lots of bad things can 
happen when one does that, and the process tends, in my 
experience, to encourage professional standardizers (which I 
think ought to be a concern about some parts of the proposed 
review process, too).

Recently, several of them have moved in the direction of what at 
least one body calls a "stable" or "mature" standard.  It takes 
special action to put something into that category but, once 
there, it is forever unless someone initiates a formal action to 
get rid of it.

I am going to try to avoid analyzing whether I think that trend 
is a good idea (certainly it is sometimes and for some classes 
of standards, but it is debatable whether we have documents in 
that class).  But, if we want to go in that direction, we might 
take a careful look at the procedures adopted by others and the 
reasons for them rather than trying to invent the wheel from 
scratch.

> I'll admit to having some double motive for this proposal,
> though - if we as a community cannot come to consensus on such
> a relatively lightweight process for doing what 2026 said we
> would do, and actually execute that process, we have (IMHO)
> proved by experiment that the community is incapable of
> supporting a "review and reclassify" function, and can safely
> assume that no such function can rationally be part of the new
> tracks we're designing.
>
> So based on that .... I argue that we should run this proposal
> now, supporting the 2026 definition of the standards track -
> and what we learn will be extremely valuable input for the
> NEWTRK discussions.

If that is what you want to do, and why, I would like to propose 
a substantive change to your draft.   As I read the draft now, 
if the Commission examines a document and decides that it should 
be retained (not moved to historic status), there is no way to 
identify the fact that the analysis has been done and a decision 
made.  I suggest, instead, that one of the following two 
actions, or both, be taken:

(i) The relevant document be identified in the various indexes 
and status registries as "affirmed" with the date the Commission 
passes over it.  This designation does not change the document's 
maturity level, but does assure any reader that the IETF has 
given it at least a superficial review since first approving it.

(ii) If the Commission concludes that an older document (say, 
more than a few years old) specifies a useful protocol, the IESG 
should be strongly encouraged to construe the combination of 
"around for several years" and "found useful" (which I think 
implies "implemented by someone") as a sufficient condition for 
immediate advancement in grade.   If there is a list of errata 
for the document, let the errata be last-called and, if no 
serious comments arise, let the document be republished with the 
errata as an appendix, but let's bias the system not just to 
cleaning out the attic, but to advancing any useful things that 
are found there with a minimum of fuss.

Note that (ii) explicitly contemplates advancing things that, if 
first proposed today, would go no where.  But, if we aren't 
ready to do that, I think the whole idea of declaring things 
historic is doomed.

      john

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 27 Apr 2004 14:53:38 -0700

--On 27. april 2004 16:24 -0400 John C Klensin <[email-masked]> wrote:

> I would like to propose a substantive change to your draft.   As I read
> the draft now, if the Commission examines a document and decides that it
> should be retained (not moved to historic status), there is no way to
> identify the fact that the analysis has been done and a decision made.  I
> suggest, instead, that one of the following two actions, or both, be
> taken:
>
> (i) The relevant document be identified in the various indexes and status
> registries as "affirmed" with the date the Commission passes over it.
> This designation does not change the document's maturity level, but does
> assure any reader that the IETF has given it at least a superficial
> review since first approving it.

I think this is a good idea. Elliot, with your editor hat on - can you 
suggest words saying that?

> (ii) If the Commission concludes that an older document (say, more than a
> few years old) specifies a useful protocol, the IESG should be strongly
> encouraged to construe the combination of "around for several years" and
> "found useful" (which I think implies "implemented by someone") as a
> sufficient condition for immediate advancement in grade.   If there is a
> list of errata for the document, let the errata be last-called and, if no
> serious comments arise, let the document be republished with the errata
> as an appendix, but let's bias the system not just to cleaning out the
> attic, but to advancing any useful things that are found there with a
> minimum of fuss.

I think this makes sense too, but would hesitate to put normative text 
saying so in the document that describes the decommissioning commission - 
I'm still arguing for "separation of concerns".....

.

---

From: John C Klensin <[email-masked]>
Date: Tue, 27 Apr 2004 18:22:11 -0400

Ok, will make a deal with you... if you/ Eliot incorporate the 
first of those suggestions, and others think the second makes 
sense, I'll write it up separately.

Brian, fwiw, I think both of these suggestions are compatible 
with either a three-stage or a two-stage standards process.  The 
second would not be needed for a one-stage process, but I 
suggest that the original suggestion wouldn't be effective there 
either (which may have been your point).  I think that the 
experience of others indicates that we would have to look at a 
reaffirm/revise/withdraw cycle along with it... and explain to 
ourselves why we wouldn't encounter the same problems as ISO, 
IEEE, ANSI, etc.   In some ways, their introduction of a 
"stabilized" or "mature" standard classification is the 
introduction of a two-level system, even though they don't call 
it that.

    john

--On Tuesday, 27 April, 2004 14:53 -0700 Harald Tveit Alvestrand 
<[email-masked]> wrote:

>
>
> --On 27. April 2004 16:24 -0400 John C Klensin
> <[email-masked]> wrote:
>
>> I would like to propose a substantive change to your draft.
>> As I read the draft now, if the Commission examines a
>> document and decides that it should be retained (not moved to
>> historic status), there is no way to identify the fact that
>> the analysis has been done and a decision made.  I suggest,
>> instead, that one of the following two actions, or both, be
>> taken:
>>
>> (i) The relevant document be identified in the various
>> indexes and status registries as "affirmed" with the date the
>> Commission passes over it. This designation does not change
>> the document's maturity level, but does assure any reader
>> that the IETF has given it at least a superficial review
>> since first approving it.
>
> I think this is a good idea. Elliot, with your editor hat on -
> can you suggest words saying that?
>
>> more than a few years old) specifies a useful protocol, the
>> IESG should be strongly encouraged to construe the
>> combination of "around for several years" and "found useful"
>> (which I think implies "implemented by someone") as a
>> sufficient condition for immediate advancement in grade.   If
>> there is a list of errata for the document, let the errata be
>> last-called and, if no serious comments arise, let the
>> document be republished with the errata as an appendix, but
>> let's bias the system not just to cleaning out the attic, but
>> to advancing any useful things that are found there with a
>> minimum of fuss.
>
> I think this makes sense too, but would hesitate to put
> normative text saying so in the document that describes the
> decommissioning commission - I'm still arguing for "separation
> of concerns".....
>
>

.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Apr 2004 11:28:57 +0200

All that's been said makes sense to me.

I'm not against Harald's desire to get started quickly. I just
don't want to see the Commission sweating over details of the
PS-->DS-->S transitions for ten year old RFCs --- but there is
plenty of scope for affirming or "historicising" older documents.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM

John C Klensin wrote:
> Ok, will make a deal with you... if you/ Eliot incorporate the first of 
> those suggestions, and others think the second makes sense, I'll write 
> it up separately.
> 
> Brian, fwiw, I think both of these suggestions are compatible with 
> either a three-stage or a two-stage standards process.  The second would 
> not be needed for a one-stage process, but I suggest that the original 
> suggestion wouldn't be effective there either (which may have been your 
> point).  I think that the experience of others indicates that we would 
> have to look at a reaffirm/revise/withdraw cycle along with it... and 
> explain to ourselves why we wouldn't encounter the same problems as ISO, 
> IEEE, ANSI, etc.   In some ways, their introduction of a "stabilized" or 
> "mature" standard classification is the introduction of a two-level 
> system, even though they don't call it that.
> 
>    john
> 
> 
.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Apr 2004 10:29:33 -0700

deal.

Eliot

.