Subject: Re: I-D Action:draft-housley-two-maturity-levels-04.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Mar 2011 10:05:22 +1300

There are numerous improvements in this version and I hope we
can get consensus soon.

Just a couple of remarks on
 5. Transition to a Standards Track with Two Maturity Levels

1) Probably there should be a statement that all existing
   Internet Standard documents are still classified as Internet Standard.
   That may seem blindingly obvious, but if we don't write it down,
   somebody will ask.

2) More substantively,

   "Any protocol or service that is currently at the Draft Standard	
    maturity level may be reclassified as an Internet Standard as soon as	
    the criteria in Section 2.2 are satisfied. This reclassification is	
    accomplished by submitting a request to the IESG along with a	
    description of the implementation and operational experience. "

I'm a bit concerned that this doesn't scale, and we will be left
with a long tail of DS documents that end up in limbo. One way to avoid
this is to encourage bulk reclassifications (rather like we did a bulk
declassification in RFC 4450). Another way is to define a sunset date,
e.g.

   Any documents that are still classified as Draft Standard two years
   after the publication of this RFC will be automatically downgraded
   to Proposed Standard.

     Brian

---

From: Tony Hansen <[email-masked]>
Date: Mon, 14 Mar 2011 17:44:31 -0400

>     That may seem blindingly obvious, but if we don't write it down,

sigh -- +1

> 2) More substantively, ...

I think both suggestions are in order. +1 and +1

     Tony Hansen

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 15 Mar 2011 02:33:24 -0500

Brian

playing devil's advocate here...

Say someone submits a request for an existing DS to the IESG and it 
takes 6 months (or 3 months) to get through the process, but only 2 
months remain before the 2 year window is up (since this RFC was 
published). Does that grandfather the DS into "the process" - meaning 
that document is no longer subject to this 'within 2 year notice' rule?

I'm just saying that this appears to beg all DS editors to get their 
DS notifications into the IESG sooner rather than later, which is 
fine, but that also creates a heck of a workload on the IESG that 
they currently do not have, does it not?

Something is going to be impacted.

James

>      Brian
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 15 Mar 2011 13:03:41 +0200

Hello,

>    after the publication of this RFC will be automatically downgraded
I'm personally not sure whether such operations will be acceptable.
If there is a Draft Standard, it means that it is more mature that
Proposed Standrad.  Therefore downgrading DSs to PSs does not seem a
good idea personally for me.  It is better to say that DSs should
remain in this maturity level until properly advanced to FS, obsoleted
or moved to Historic status.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Mar 2011 08:11:00 -0400

On Tue, Mar 15, 2011 at 3:33 AM, James M. Polk <[email-masked]> wrote:

Brian
> Say someone submits a request for an existing DS to the IESG and it takes 6
> months (or 3 months) to get through the process, but only 2 months remain
> before the 2 year window is up (since this RFC was published). Does that
> grandfather the DS into "the process" - meaning that document is no longer
> subject to this 'within 2 year notice' rule?
>
> I'm just saying that this appears to beg all DS editors to get their DS
> notifications into the IESG sooner rather than later, which is fine, but
> that also creates a heck of a workload on the IESG that they currently do
> not have, does it not?
>

Make it a 2 year deadline for receiving requests. Problem solved.

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

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 15 Mar 2011 10:13:51 -0700

>     after the publication of this RFC will be automatically downgraded

Brian,

Certainly a reasonable concern.  However...

1.  While the accounting ugliness of leaving these untouched is obvious, I am 
less clear about the practical trouble they cause.  We should gain some public 
agreement that this is seriousness enough to worry about, and why.

2. Automatic reclassification strikes me as dangerous and likely to have serious 
unintended consequences.  I believe we do not have a history of having done 
anything like this, in spite of our rules, except for aging out I-Ds.

3. Your's specific proposal assumes ready availability of workers for documents 
that are used.  In fact, the folks who use specs are often far removed from the 
IETF and neither aware of IETF activities nor available to contribute to them. 
This is an example of a downside likely to downgrade docs inappropriately, IMO.

Alas, I don't have a constructive, alternative suggestion.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Brian Carpenter <[email-masked]>
Date: Wed, 16 Mar 2011 08:05:17 +1300

On Wed, Mar 16, 2011 at 1:11 AM, Phillip Hallam-Baker <[email-masked]> wrote:
>> Say someone submits a request for an existing DS to the IESG and it takes
>> 6 months (or 3 months) to get through the process, but only 2 months remain

Yes, good idea.

     Brian

---

From: Brian Carpenter <[email-masked]>
Date: Wed, 16 Mar 2011 08:09:01 +1300

> or moved to Historic status.

All our experience shows that unless we have a firm sunset date, the job
will never be finished and in fifty years there will still be DS documents.

If nobody cares - the document will be downgraded. What's the problem
with that? It will still be on the standards track.

(Automatic downgrading to Historic would be a different matter.)

     Brian

---

From: Brian Carpenter <[email-masked]>
Date: Wed, 16 Mar 2011 08:13:13 +1300

On Wed, Mar 16, 2011 at 6:13 AM, Dave CROCKER <[email-masked]> wrote:
> 1.  While the accounting ugliness of leaving these untouched is obvious, I
> am less clear about the practical trouble they cause.  We should gain some
> public agreement that this is seriousness enough to worry about, and why.
>
> 2. Automatic reclassification strikes me as dangerous and likely to have
> serious unintended consequences.  I believe we do not have a history of
> having done anything like this, in spite of our rules, except for aging out
> I-Ds.
>
> 3. Your's specific proposal assumes ready availability of workers for
> documents that are used.  In fact, the folks who use specs are often far
> removed from the IETF and neither aware of IETF activities nor available to
> contribute to them. This is an example of a downside likely to downgrade
> docs inappropriately, IMO.
>

There's a fairly obvious alternative, which is to <shrug> about the widespread
deployment rule and promote all existing DS automatically to Internet Standard.

That wouldn't shock me - and it would be a lot less work for everybody.
We could still require widespread deployment for future documents.

     Brian

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 15 Mar 2011 17:08:13 -0500

> > Make it a 2 year deadline for receiving requests. Problem solved.

thanks

james

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 Mar 2011 23:22:54 +0100 (MET)

Dave CROCKER wrote:
> Brian E Carpenter wrote:
> 1.  While the accounting ugliness of leaving these untouched is obvious,
> I am less clear about the practical trouble they cause.  We should gain
> some public agreement that this is seriousness enough to worry about,
> and why.
> 
> serious unintended consequences.

I don't understand the motivation about changing anything about
the status of documents that have already been published.

Among the original complaints there were the two:

 - the IETF is confusing the non-IETFers about the standardization
   with its three levels of document maturity

 - the bar for Proposed is too high and ought to be lowered.

Unless the clear intent and IETF consensus is to add

 - mislead _everyone_ about the real document maturity of *ALL*
   IETF documents, including all existing documents

 - penalize all folks did put effort into going to "Draft Standard"
   by completely nixing their effort two years later.

the status of the existing documents should NOT be touched by any new
rules for publishing documents as Proposed Standards.

To make clear which documents were issued under the original regime
and which were issued under the new, there should probably be
an obvious gap in the number range (going to 5 digit or 6 digit numbers).

-Martin

---

From: Bill McQuillan <[email-masked]>
Date: Tue, 15 Mar 2011 15:50:56 -0700

> rules for publishing documents as Proposed Standards.

  +1

> an obvious gap in the number range (going to 5 digit or 6 digit numbers).

  -1 (simple sequentially increasing RFC numbers for all items is fine)

-- 
Bill McQuillan <[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Mar 2011 12:08:31 +1300

>    IETF documents, including all existing documents

If we do the reclassification correctly, nobody will be misled.

>    by completely nixing their effort two years later.

That's why my personal preference is what I already suggested -
just label them all as Internet Standard. But in fact, the
proposed bar for promotion from DS to Internet Standard is pretty
low. I doubt that any deserving document will lose out.

There are 85 DS documents today. If each IETF Area does its own
bulk promotion, that averages at 12 documents per area -
not an enormous job.

> rules for publishing documents as Proposed Standards.

Disagree. If we don't reclassify, people will be puzzled for the
next 50 years by the residual DS documents.

> an obvious gap in the number range (going to 5 digit or 6 digit numbers).

Oh, have you any guess how many tools will be broken by the RFC10K problem?

(That is not a joke.)

   Brian

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Mar 2011 09:46:48 +0200

> Oh, have you any guess how many tools will be broken by the RFC10K problem?

By looking at http://arkko.com/tools/rfcstats/pubdistr.html

The RFC10K problem will hit us around 2020 (assuming the publication rate keeps increasing)

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 16 Mar 2011 09:15:26 -0700

On 3/15/2011 4:08 PM, Brian E Carpenter wrote:
> just label them all as Internet Standard.

Classifying specs as full standards, when there is no evidence that the criteria 
for Full are satisfied, is a good way to instantly de-value Full Standard.

 > But in fact, the

You think that successful deployment and use is a low bar?

Most Internet experience is that gaining real-world deployment and use is far 
more difficult than getting the spec published...

> next 50 years by the residual DS documents.

No doubt there will be some folks are confused.  But the reality is that there 
will always be some people who are confused, for any issue, no matter what is 
done to prevent it.  Certainly we have plenty of demonstration that this is a 
universal, yet somehow we've survived and even flourished.

So that doesn't make a very useful criterion.  A more useful criterion would be 
demonstrating that the confusion causes significant problems.

d/
-- 

   Dave Crocker

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 18 Mar 2011 16:22:34 +0200

Hello all,

We reached the conclusion that the sunset period of 2 years for 
advancing DSs to FSs or downgrading of them.  However there are some 
issues that should also be discussed, such as making references to DSs 
during this period, DSs already in IESG processing, etc.

So, I propose to mention that:

> During this period Full Standards as well as Proposed Standards are 
> allowed to make normative references to Draft Standards. 

Regarding DSs already in IESG processing:

> Upon approval of this document IESG SHALL NOT accept any requests for 
> advancing of Proposed Standards to Draft Standards.  Those documents 
> that, at the time of publication of this document, will already be in 
> IESG processing for advancing to Draft Standards SHOULD automatically 
> be considered for advancing to Full Stndard; however IESG, on their 
> own discretion, MAY decide on discarding such document for further 
> work on it.
Another question is what should be done with RFC 5657 
(http://tools.ietf.org/html/rfc5657), that is related to DSs, that are 
terminated by the proposed document.  My proposal is to make it update 
RFC 5657 and mention that is changes its sphere of action to advancing 
to FSs.

Any other ideas?

Mykyta Yevstifeyev