prerequisite for change (was Re: draft-housley-two-maturity-levels)

[Scott O. Bradner]

I've previously expressed my opinion that proposals to muck with the
number of steps in teh IETF standards process will no do anything
useful (i.e., will not be effective) - JOhn and I have just posted
what, to us, would be a prerequisite for amy process mucking proposal
to succeed

Scott

-
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Subject: I-D Action:draft-bradner-restore-proposed-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title   : Restoring Proposed Standard to Its Intended Use
Author(s)   : J. Klensin, S. Bradner
Filename: draft-bradner-restore-proposed-00.txt
Pages   : 6
Date: 2011-01-29

Restore the very low bar for Proposed Standard described in RFC 2026
(BCP 9)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bradner-restore-proposed-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)

[Brian E Carpenter]

Hi Scott and John,

I don't see this as inconsistent with the current 2-stage proposal,
if the latter's omission of a requirement for independent interoperable
implementations for stage 2 is corrected.

I don't, however, believe that the problems are separable.
The bar for PS has crept up, IMHO, precisely because the bar
for DS/STD has appeared too high to be readily attainable.

So I see two ways forward that hang together:

1. draft-bradner-restore-proposed +
(draft-housley-two-maturity-levels + independent interoperable implementations)

2. draft-loughney-newtrk-one-size-fits-all-01 (i.e. simply abolish
the second and third stages, and make interoperability reports optional)

I prefer #1.

Regards
   Brian

On 2011-01-30 11:39, Scott O. Bradner wrote:
> I've previously expressed my opinion that proposals to muck with the
> number of steps in teh IETF standards process will no do anything
> useful (i.e., will not be effective) - JOhn and I have just posted
> what, to us, would be a prerequisite for amy process mucking proposal
> to succeed
> 
> Scott
> 
> -
> From: internet-dra...@ietf.org
> To: i-d-annou...@ietf.org
> Subject: I-D Action:draft-bradner-restore-proposed-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
>   Title   : Restoring Proposed Standard to Its Intended Use
>   Author(s)   : J. Klensin, S. Bradner
>   Filename: draft-bradner-restore-proposed-00.txt
>   Pages   : 6
>   Date: 2011-01-29
> 
> Restore the very low bar for Proposed Standard described in RFC 2026
> (BCP 9)
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bradner-restore-proposed-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)

[John C Klensin]

--On Sunday, January 30, 2011 1:01 PM +1300 Brian E Carpenter
 wrote:

> Hi Scott and John,
> 
> I don't see this as inconsistent with the current 2-stage
> proposal, if the latter's omission of a requirement for
> independent interoperable implementations for stage 2 is
> corrected.

I won't try to speak for Scott, but I agree.

> I don't, however, believe that the problems are separable.
> The bar for PS has crept up, IMHO, precisely because the bar
> for DS/STD has appeared too high to be readily attainable.

I think one can read the symptoms, and cause-effect
relationships, in different ways.  However, I think it is safe
to say that --

* as the bar for PS creeps up, there is less energy,
inclination, and motivation to move toward DS/STD

* as the percentage of documents --out of those that
represent specifications of protocols anyone cares about
-- that are actually advanced to DS/STD goes down, the
incentives to raise the bar for PS increase.

In other words, regardless of what one believes about cause and
effect, there is a positive feedback loop operating here.

Collapsing STD onto DS is unlikely to affect that loop.  There
has been no evidence offered that such a collapse will increase
the number of documents that advance to that level.   Indeed, by
_adding_ requirements to a combined DS/STD level, it is at least
as likely to raise the perceived threshold for getting to DS/STD
without significantly increasing the motivation to push
documents into that level.

On the other hand, reverting the definition of PS both makes
that level faster and increases the motivation to move a
document to DS/STD because that second level become the first
one at which a reader can really expect a complete and
comprehensive spec.

That is why we used used the term "prerequisite".

> So I see two ways forward that hang together:
> 
> 1. draft-bradner-restore-proposed +
> (draft-housley-two-maturity-levels + independent interoperable
> implementations)
> 
> 2. draft-loughney-newtrk-one-size-fits-all-01 (i.e. simply
> abolish the second and third stages, and make interoperability
> reports optional)

> I prefer #1.

So do I.  But we agree that, absent the commitment to
interoperability testing as a critical part of the standards
process -- the one thing we claimed for years was what made IETF
work almost unique and almost uniquely successful among SDO--
there is little value in having a multiple-step process.

regards,
  john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)

[Phillip Hallam-Baker]

I believe this proposal to be dangerous and undesirable.

The fact is that the three stage process has never worked. As in not ever.
If you take a look at the current Internet standards over half of the total
are grandfathered from before the IETF was started.

You cannot return to a state that never existed.


The raising of the bar for proposed standard has a very simple reason: it is
now almost impossible to change specifications once deployed. There is no
point in conducting a security review after the RFC has issued, it is too
late. Similarly there is no point in checking to see if the Gen Art criteria
are met.

Another factor here is that many specifications coming to IETF have already
had significant work done.



On Sat, Jan 29, 2011 at 5:39 PM, Scott O. Bradner  wrote:

>
> I've previously expressed my opinion that proposals to muck with the
> number of steps in teh IETF standards process will no do anything
> useful (i.e., will not be effective) - JOhn and I have just posted
> what, to us, would be a prerequisite for amy process mucking proposal
> to succeed
>
> Scott
>
> -
> From: internet-dra...@ietf.org
> To: i-d-annou...@ietf.org
> Subject: I-D Action:draft-bradner-restore-proposed-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>Title   : Restoring Proposed Standard to Its Intended Use
>Author(s)   : J. Klensin, S. Bradner
>Filename: draft-bradner-restore-proposed-00.txt
>Pages   : 6
>Date: 2011-01-29
>
> Restore the very low bar for Proposed Standard described in RFC 2026
> (BCP 9)
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bradner-restore-proposed-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)

[Andrew Sullivan]

On Sun, Jan 30, 2011 at 09:27:17AM -0500, Phillip Hallam-Baker wrote:

> The raising of the bar for proposed standard has a very simple reason: it is
> now almost impossible to change specifications once deployed.

That's an argument for _no_ maturity levels, then, not for two.   

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)

[Keith Moore]

On Jan 30, 2011, at 9:58 AM, Andrew Sullivan wrote:

> On Sun, Jan 30, 2011 at 09:27:17AM -0500, Phillip Hallam-Baker wrote:
> 
>> The raising of the bar for proposed standard has a very simple reason: it is
>> now almost impossible to change specifications once deployed.
> 
> That's an argument for _no_ maturity levels, then, not for two.   

Is there an implicit assumption here that more standards (presumably of poorer 
quality) is a good thing?

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)

[Andrew Sullivan]

On Sun, Jan 30, 2011 at 10:15:01AM -0500, Keith Moore wrote:
> > 
> > That's an argument for _no_ maturity levels, then, not for two.   
> 
> Is there an implicit assumption here that more standards (presumably of 
> poorer quality) is a good thing?

Not on my part.  I'm merely observing that, if the claim is that you
can't alter deployed protocols, then there's no reason to say that we
need two maturity levels, because in fact nothing will advance past
the first stage anyway.

Phillip's description of the state of affairs is consistent with what
we actually see today in a three-maturity-level system: nothing moves
past the first level.  But if the problem is that you can't alter a
deployed spec, then no matter how many levels we pare off past the
first, nothing will move to those higher levels, because it's only the
first level that counts.

I'm not happy about this, note.  I'm just making an observation about
what is entailed by Phillip's description.

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)

[Keith Moore]

On Jan 30, 2011, at 10:35 AM, Andrew Sullivan wrote:

> On Sun, Jan 30, 2011 at 10:15:01AM -0500, Keith Moore wrote:
>>> 
>>> That's an argument for _no_ maturity levels, then, not for two.   
>> 
>> Is there an implicit assumption here that more standards (presumably of 
>> poorer quality) is a good thing?
> 
> Not on my part.  

Sorry, I didn't mean to imply that it was your assumption.  I do wonder if it's 
an assumption held by many in the discussion.

> I'm merely observing that, if the claim is that you
> can't alter deployed protocols, then there's no reason to say that we
> need two maturity levels, because in fact nothing will advance past
> the first stage anyway.

As far as I can tell, the principal reason any specifications move beyond 
Proposed is that they are widely deployed and their limitations become 
apparent.  So I think you can alter deployed protocols, but only if the 
protocols or their implementations are seen to be sufficiently broken.

(Which could lead one to conclude, from a perverse point-of-view, that some 
flaws should be left in at Proposed Standards so that they'll have to be fixed 
later, so that we can get more Draft and Full Standards published.)

Keith


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)

[Dave CROCKER]

On 1/30/2011 7:35 AM, Andrew Sullivan wrote:

Is there an implicit assumption here that more standards (presumably of
poorer quality) is a good thing?


Not on my part.  I'm merely observing that, if the claim is that you can't
alter deployed protocols, then there's no reason to say that we need two
maturity levels, because in fact nothing will advance past the first stage
anyway.


The current proposal specifies a second maturity level that does not permit 
changing the technical specification.




But if the problem is that you can't alter a deployed spec, then no matter
how many levels we pare off past the first, nothing will move to those higher
levels, because it's only the first level that counts.


The rationale for the second level concerns assessment of success, not changes
to the protocol.

So the basis upon which the second level will succeed or fail has nothing to do
with the criterion you are citing.

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)

[Andrew Sullivan]

On Sun, Jan 30, 2011 at 07:49:44AM -0800, Dave CROCKER wrote:
>> Not on my part.  I'm merely observing that, if the claim is that you can't
>> alter deployed protocols, then there's no reason to say that we need two
>> maturity levels, because in fact nothing will advance past the first stage
>> anyway.
>
> The current proposal specifies a second maturity level that does not 
> permit changing the technical specification.

Yes, I know.  I fail completely to see why anyone would ever do the
work for such movement of maturity level.  The proposal seems to me to
be something along the lines of giving gold stars to protocols with
people who are willing to do the busywork.  I don't have any special
objection to the proposal, and I don't really have strong feelings
about whether it goes anywhere.  But I don't believe it will change
things very much, and it feels to me more like a bureaucratic
improvement than something that helps IETF participants and consumers
of IETF protocols.

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)

[Phillip Hallam-Baker]

On Sun, Jan 30, 2011 at 9:58 AM, Andrew Sullivan  wrote:

> On Sun, Jan 30, 2011 at 09:27:17AM -0500, Phillip Hallam-Baker wrote:
>
> > The raising of the bar for proposed standard has a very simple reason: it
> is
> > now almost impossible to change specifications once deployed.
>
> That's an argument for _no_ maturity levels, then, not for two.
>

Not at all, many protocols are never successfully deployed.

In the case that a protocol is successfully deployed, the final protocol has
frequently required major modification. Documenting those changes has value.


-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: prerequisite for change (was Re: draft-housley-two-maturity-levels)

[Dave CROCKER]

On 1/30/2011 8:06 AM, Andrew Sullivan wrote:

On Sun, Jan 30, 2011 at 07:49:44AM -0800, Dave CROCKER wrote:

The current proposal specifies a second maturity level that does not
permit changing the technical specification.


Yes, I know.  I fail completely to see why anyone would ever do the
work for such movement of maturity level.  The proposal seems to me to
be something along the lines of giving gold stars to protocols with
people who are willing to do the busywork.



One of the challenges in the discussion of this topic on the IETF list is some 
very different models of the role of a standards label.  Given the frequent view 
that only technical details matter, one would think that we are composed only of 
engineers who give little thought to organizational, social and psychological 
factors that might also affect adoption decisions...


One curiosity about this is that our documentation style for specifications 
permits far more tutorial and explanatory content than most other standards 
group, which one might take to indicate that we actually worry a bit about those 
who will adopt our work and that we actually want to help them.  Yet our 
organization mode tends to consider 'publication' the end of our concern.


As folks in the communications game, the IETF tends to have a curious lack of 
interest in the 'feedback' portion of a Shannon-Weaver model[1], when it comes 
to protocol adoption.  It's as if we stopped reading after the first Shannon 
paper.[2]


In any event, I thought the value proposition of the proposal's second label had 
been discussed at some length:


   For significant portions of industry, the decision whether to adopt new 
technology relies heavily on an assessment of its stability and likely success. 
 Some specs are nascent and fluid.  Some are failed.  Others are successful. As 
of now, it can be difficult for such folk to distinguish the real maturity of 
IETF proposals, since most are at Proposed.


   So the proposal defines a second stage that serves the purpose of making an 
official statement of stability and success, by virtue of noting significant 
deployment.  That can be helpful during the "market expansion" phase of adoption.


d/


[1] 

[2] 
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf