Subject: Re: draft-housley-two-maturity-levels

From: Russ Housley <[email-masked]>
Date: Mon, 24 Jan 2011 12:37:10 -0500

draft-housley-two-maturity-levels-03 was just posted.  It reflects much of the discussion on this thread over the last few months.  In particular, it embraces the changes put forward in the recent proposal by Dave Crocker, Eric Burger, Peter Saint-Andre, and Spencer Dawkins.  Please take a look at the revised document, and provide your thoughts.

Russ

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Jan 2011 11:30:42 -0700

On 1/24/11 10:37 AM, Russ Housley wrote:
> draft-housley-two-maturity-levels-03 was just posted.  It reflects
> much of the discussion on this thread over the last few months.  In
> particular, it embraces the changes put forward in the recent
> proposal by Dave Crocker, Eric Burger, Peter Saint-Andre, and Spencer
> Dawkins.  Please take a look at the revised document, and provide
> your thoughts.

Thanks, Russ.

A few comments:

1. It's not clear to me if this is quite correct in the Introduction:

   Similarly, subsequent revisions to the
   documents ought to be easier to publish, whether the document is
   advancing on the maturity ladder or not.

As discussion later in the I-D reveals, we don't want to make it easy
for folks to publish subsequent revisions that are significant, we want
to make it easy to publish adjustments based on implementation and
deployment experience:

   Experience with a Proposed Standard often leads to revisions that
   clarify, modify, enhance, or remove features.

See also:

   A specification may be, and indeed, is likely to be, revised as it
   advances from Proposed Standard to Internet Standard.  When a revised
   specification is proposed for advancement to Internet Standard, the
   IESG shall determine the scope and significance of the changes to the
   specification, and, if necessary and appropriate, modify the
   recommended action.  Minor revisions and the removal of unused
   features are expected, but a significant revision may require that
   the specification accumulate more experience at Proposed Standard
   before progressing.

I suggest:

   Similarly, it ought to be easier to publish revisions that
   incorporate implementation and deployment experience, whether the
   document is advancing on the maturity ladder or not.

2. I found this statement to be strange:

   The intention of the two-tier maturity
   ladder is to restore the requirements for Proposed Standard from RFC
   2026.

Why "restore"? Have they been superseded or ignored? I suggest "retain".

3. I think there is a word missing here:

   The rules that make references to documents at
   lower maturity levels are a major cause of stagnation in the
   advancement of documents.

Perhaps "The rules prohibiting references..."?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 24 Jan 2011 13:39:26 -0500

It seems to me that this proposal strikes a good balance in making an 
effort to improve the situation regarding our document track.

Regarding the particular clause:

On 1/24/2011 1:30 PM, Peter Saint-Andre wrote:
...
> Why "restore"? Have they been superseded or ignored? I suggest "retain".

I think the use of the word "restore" is very important. Over the years, 
our informal requirements and our sense of what was needed for Proposed 
Standard have moved up noticeably.  This reflected a number of factors, 
all of them driven as best I can tell by good intentions.
Restoring the lower bar for PS is probably the most direct benefit this 
proposal can have on our work.

Separately, the replacement of the requirement for verified 
interoperability with the assumption of interoperability based on wide 
deployment is an understandable compromise.  I am not sure I like this 
change, but I can live with it, which is good enough.

I do like the more relaxed wording on the removal of unused features.

Yours,
Joel M. Halpern

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Jan 2011 11:44:35 -0700

> proposal can have on our work.

Aha: so restore operationally. That makes sense.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 24 Jan 2011 13:57:03 -0500

On Mon, Jan 24, 2011 at 1:39 PM, Joel M. Halpern <[email-masked]>wrote:

> Standard have moved up noticeably.  This reflected a number of factors, all
> of them driven as best I can tell by good intentions.

I would like that to be possible, but I would settle for just being able to
make Standard status feasible.

One of the side effects of most drafts deadlocking at Proposed is that
people don't want to let anything 'bad' go through and that often means
something that people 'feel uncomfortable with'.

-- 
Website: http://hallambaker.com/

---

From: Tony Hansen <[email-masked]>
Date: Mon, 24 Jan 2011 23:13:49 -0500

On 1/24/2011 12:37 PM, Russ Housley wrote:
> draft-housley-two-maturity-levels-03 was just posted. ...

Overall I find this spec to be an improvement over the previous version. 
Here are a few areas where improvements can be made.

====

This phrase in Section 1:

     In addition,
     IETF working groups and IESG members providing much more scrutiny
     than is called for by RFC 2026 [1] prior to publication as Proposed
     Standard.

is not a sentence. Should it be "provide"? Should it be "have been 
providing"? Something else?

====

The sentence in Section 1

     One desired outcome is to provide an environment where the
     IETF community is able to publish Proposed Standards as soon
     as rough consensus is achieved.

and these sentences in Section 2.1:

     The intention of the two-tier maturity
     ladder is to restore the requirements for Proposed Standard from RFC
     2026. No new requirements are introduced; no existing published
     requirements are relaxed.

together lay out what is required for PS. Disregarding the other 
arguments over the word "restore", these sentences are otherwise fine 
and dandy.

But I think there needs to be further guidance provided to the IESG and 
Working Groups on how they should change their behavior. What is wrong 
with how the WGs and IESG are currently interpreting the rules of 2026 
for PS? What current behaviors differ or have gone beyond what 2026 
requires, and hence need to be changed to restore those requirements? 
Without such guidance, nothing changes.

====

One major section that has been removed from the previous version of 
this I-D is what to do with documents currently in the Draft Standard 
status. I know that there was significant disagreement with the 
"automatic reclassification to Internet Standard" proposed before, with 
good reason.

I'm going to letter the the rules in section 2.2 as follows. I'm also 
going to indicate how these sort of map into the old classifications:

     a) technical maturity (DS => FS)
     b) belief in significant benefit to Internet community (DS => FS)
     c) significant number of implementations with successful 
operational experience (DS => FS)
     d) no unresolved errata (PS => DS)
     e) no unused features that increases implementation complexity (PS 
=> DS)

Some people have argued that having a significant number of 
implementations (c) is sufficient to demonstrate both technical maturity 
(a) and the belief in benefit (b). The (d) and (e) requirements have 
already been demonstrated by virtue of those RFCs already being at DS 
status, although additional errata may have been filed against the DS.

So I'm going to suggest that the following be applied to documents that 
are currently in Draft Standard status:

     Any protocol or service that is currently in Draft Standard status, 
without
     significant unresolved errata, may be reclassified as an Internet 
Standard
     as soon as it can be demonstrated to have a significant number of
     implementations with successful operational experience.

     This reclassification may be accomplished by filing a request with 
the IESG,
     detailing the Implementation and Operational Experience. After 
review, the
     IESG will hold an IETF-wide Last Call on the reclassification. If 
there is consensus
     for the reclassification, the RFC will be reclassified without 
being reissued.

     Protocols and services that have significant unresolved errata will 
need to be
     re-issued to resolve the errata before the above criteria can be 
applied.

Of course, there is still an open question what it means to have a 
"significant number", which will remain as subjective as it was before 
with the 2026 rules.

     Tony Hansen
     [email-masked]

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 25 Jan 2011 08:19:51 +0200

25.01.2011 6:13, Tony Hansen wrote:
> Overall I find this spec to be an improvement over the previous 
> version. Here are a few areas where improvements can be made.
>
> ====
> [. . . . .]
>
> ====
>
> "automatic reclassification to Internet Standard" proposed before, 
> with good reason.
>
> implementations (c) is sufficient to demonstrate both technical 
> maturity (a) and the belief in benefit (b). The (d) and (e) 
> requirements have already been demonstrated by virtue of those RFCs 
> already being at DS status, although additional errata may have been 
> filed against the DS.
>
> So I'm going to suggest that the following be applied to documents 
> that are currently in Draft Standard status:
>
>     Any protocol or service that is currently in Draft Standard 
> status, without
>     Protocols and services that have significant unresolved errata 
> will need to be
Russ, Tony, all,

I think that Section 5, regarding STD numbers, does not fully introduce 
the topic and is not acceptable.  So I'd like to propose the following 
solution: the STD numbers are splitted into two groups: STD P-xxx and 
STD F-xxx, for proposed and full standards and assigned to all 
Standards-Track document once they move to one of these levels.   The 
number must then be the same for P- and F- groups, with one of them 
reserved while the doc is in the other level.  I.e. the doc is PS - STD 
F-xxx is reserved and vice versa.

This, IMO, will resolve the problem with STD numbers.

As for the issue with Draft Standards, I find that Tony proposed 
acceptable.  But we should mention that if reclassification to FS did 
not gain the consensus, the spec. is reclassified to Proposed Standard.

All the best,
Mykyta Yevstifeyev
>
>     Tony Hansen
>     [email-masked]
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: [email-masked]
Date: Wed, 26 Jan 2011 14:11:25 -0800 (PST)

+1 to the proposed rules for reclassifying DS to IS. I think they offer a
reasonable balance between expediency and quality.

				Ned