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

From: [email-masked] (Scott O. Bradner)
Date: Wed, 26 Jan 2011 22:29:24 -0500 (EST)

1/ I still do not think this (modified) proposal will have any real
   impact on the number of "Proposed Standard" documents that move
   to a (in this proposal, "the") higher level since I do not see
   how this makes any significant changes to the underlying reasons
   that documents have not progressed in the past - i.e., I see no
   reason to think that this proposal would change the world much
   (would not help, would not hurt)

2/ I think the proposal must specifically deal with the 2026 IPR licence
   requirement in section 4.1.2

      If patented or otherwise controlled technology
      is required for implementation, the separate implementations must
      also have resulted from separate exercise of the licensing process.

   The requirement can be dealt with by explicitly discarding 
   it or by including it. But not mentioning the requirement does
   not make the issue go away.  This requirement was, in theory, a
   way to keep the IETF/IESG out of the business of evaluating
   the fairness of licensing terms.  I can remember only
   one time it came up (in an appeal) so getting rid of it may
   be fine - but don't make it look like it was just forgotten.
 
3/ I think you also be quite specific as to how to decide that the
   conditions for advancement have been met - one of the big
   implementation issues with 2026 was knowing how to decide
   that a technology was ready to be advanced (did you need
   a spreadsheet listing all features and noting with ones
   had been multiply implemented (as was done at huge effort
   for HTTP 1.1) or is there someting simplier - clear rules 
   would help avoid this type of issue in the future

4/ as part of #3 - the rules should also specifically deal with
   the following pp from 2026

      The requirement for at least two independent and interoperable
      implementations applies to all of the options and features of the
      specification.  In cases in which one or more options or features
      have not been demonstrated in at least two interoperable
      implementations, the specification may advance to the Draft Standard
      level only if those options or features are removed.

   this requirement was included to try to remove cruft from protocols
   as they went forward - maybe this is no longer a desire but,
   like with the license issue, a specific mention of what has
   been decided would mean that people would not think that
   things were not just forgotton.

Scott

---

From: John C Klensin <[email-masked]>
Date: Thu, 27 Jan 2011 02:28:59 -0500

+1 on all points, especially the first one.

   john

--On Wednesday, January 26, 2011 22:29 -0500 "Scott O. Bradner"
<[email-masked]> wrote:

> 
> 1/ I still do not think this (modified) proposal will have any
> real    impact on the number of "Proposed Standard" documents
> that move    to a (in this proposal, "the") higher level since
> I do not see    how this makes any significant changes to the
> underlying reasons    that documents have not progressed in
> the past - i.e., I see no    reason to think that this
> proposal would change the world much    (would not help, would
> not hurt)
> 
> 2/ I think the proposal must specifically deal with the 2026
> IPR licence    requirement in section 4.1.2
> 
>       is required for implementation, the separate
> implementations must       also have resulted from separate
> exercise of the licensing process.
> 
>    it or by including it. But not mentioning the requirement
> does    not make the issue go away.  This requirement was, in
> theory, a    way to keep the IETF/IESG out of the business of
> evaluating    the fairness of licensing terms.  I can remember
> only    one time it came up (in an appeal) so getting rid of
> it may    be fine - but don't make it look like it was just
> forgotten.  
> 3/ I think you also be quite specific as to how to decide that
> the    conditions for advancement have been met - one of the
> big    implementation issues with 2026 was knowing how to
> decide    that a technology was ready to be advanced (did you
> need    a spreadsheet listing all features and noting with ones
>       The requirement for at least two independent and
> interoperable       implementations applies to all of the
> options and features of the       specification.  In cases in
> which one or more options or features       have not been
> demonstrated in at least two interoperable
> implementations, the specification may advance to the Draft
> Standard       level only if those options or features are
> removed.
> 
>    this requirement was included to try to remove cruft from
> protocols    as they went forward - maybe this is no longer a
> desire but,    like with the license issue, a specific mention
> of what has    been decided would mean that people would not
> think that    things were not just forgotton.
> 
> Scott
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 27 Jan 2011 09:41:45 +0200

Hi,

yes, I also agree the first one is the most important point and has not
been addressed so far. If we want a system that works (and is used), it
needs to include incentives to move from one level to the next one. I
have discussed this issue with quite a few people. Some people claim
that those incentives exist in some areas (e.g., public institutions
preferring or requiring full standards in their RFQs) but, at least in
the RAI area, the incentives are not there in the vast majority of cases.

Cheers,

Gonzalo

---

From: John C Klensin <[email-masked]>
Date: Thu, 27 Jan 2011 04:10:22 -0500

--On Thursday, January 27, 2011 09:41 +0200 Gonzalo Camarillo
<[email-masked]> wrote:

> Hi,
> 
> yes, I also agree the first one is the most important point
> and has not been addressed so far. If we want a system that
> works (and is used), it needs to include incentives to move
> from one level to the next one. I have discussed this issue
> with quite a few people. Some people claim that those
> incentives exist in some areas (e.g., public institutions
> preferring or requiring full standards in their RFQs) but, at
> least in the RAI area, the incentives are not there in the
> vast majority of cases.

Gonzalo,

Suppose we were to succeed in returning Proposed Standard to its
intended purpose --  more or less a good rough sketch of a
protocol, suitable for implementation and testing with the
support of mailing list discussions -- and being completely
clear about what that meant.   I think the incentives to advance
to a more complete specification that represented community
consensus about its being implementable and probably useful
would then be clear.

That change clearly requires our being very clear internally
that Proposed Standard is a lightweight spec with a lightweight
approval process: if we can't get away from the mentality of
"you made me review this, so I have to find at least something
to comment on and ask for changes" in the various review teams
and the IESG, I think it is pretty much hopeless and that
draft-housley-two-maturity-levels will turn out to accomplish
exactly nothing other than to eliminate whatever further
specification refinement occurs in the few documents that now to
to Full Standard.

As long as we apply a very high bar to entry for Proposed
Standard and insist that specifications at that level are
perfectly good standards, there will rarely be an incentive to
move to the second level, no matter what we call it and whether
or not there is a third level.

I think the change, and the incentives, might be reinforced by
renaming "Proposed" to "Rough Preliminary Specification" or
something else without "Standard" in its name, but that is a
separate matter.

best,
    john

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 27 Jan 2011 12:35:04 -0800

>     be fine - but don't make it look like it was just forgotten.

Please note that this reply is only about Scott's friendly amendment for one 
added sentence to cover "interoperability" about IPR:

+1

It's terse, relevant and seems pragmatic.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Doug Barton <[email-masked]>
Date: Thu, 27 Jan 2011 13:50:38 -0800

> something else without "Standard" in its name, but that is a

I've made this statement before, so I'll only touch on it briefly. The 
world outside the IETF does not understand the difference between our 
various flavors of "RFC" now. There is absolutely no hope of refining 
that understanding EXternally when we can't even follow it consistently 
INternally.

To some extent I think Russ' draft accurately reflects the status quo, 
namely that drafts are the new proposed, and that proposed is the new 
deployed. I'm hesitant to provide full-throated support for the draft 
for a few reasons:

1. To the extent that anyone still cares that I once managed the IANA I 
don't want to appear to be trying to influence the IETF's processes.
2. As an IETF participant I haven't fully thought through all the 
ramifications of the draft.
3. As both an IETF participant and as a consumer of the standards we 
create I still believe (as I've said previously) that what we need is 
not an evolution, but a revolution; with different names for things that 
more accurately reflect their status and intended use. However, it's 
pretty obvious at this point that there is no broad support for this 
position, so I won't waste more time on it.

hth,

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: SM <[email-masked]>
Date: Thu, 27 Jan 2011 17:36:26 -0800

>    (would not help, would not hurt)

If this draft is published, there may be more documents moving to the 
next level.  There has been some comments about stated requirements 
for Proposed Standard being restored.  It requires more than a BCP 
for that to happen.

In Section 2:

  "Reconsideration of the portions that were previously approved for
   publication as a Proposed Standard requires evidence that the
   unchanged features are causing harm to the Internet."

I gather that there won't be any requirement for interoperability.

That draft does not say which sections of RFC 2026 are being 
updated.  As I do not have any IETF experience, I'll defer to what 
the elders of the IETF have to say about BCP 9 if it ever becomes 
subject to interpretation. :-)

>something else without "Standard" in its name, but that is a

The constituency has a lot of authors of documents which are at 
"Proposed Standard".  A name change will face strong resistance 
unless it is at least at par with the current gold standard.

At 13:50 27-01-11, Doug Barton wrote:
>I've made this statement before, so I'll only touch on it briefly. 
>The world outside the IETF does not understand the difference 
>between our various flavors of "RFC" now. There

As it is probably the consensus of the IETF that the world inside the 
IETF understands the difference, it is not worth arguing about.

>create I still believe (as I've said previously) that what we need 
>is not an evolution, but a revolution; with different names for 
>things that more accurately reflect their status and intended use. 
>However, it's pretty obvious at this point that there is no broad 
>support for this position, so I won't waste more time on it.

A revolution is only possible if the world runs out of IPv4 addresses 
or if there is support from business constituency, whichever happens later.

Regards,
-sm

---

From: Martin Rex <[email-masked]>
Date: Fri, 28 Jan 2011 03:30:43 +0100 (MET)

>    (would not help, would not hurt)

The reason why so many documents are at proposed is that they're
often collections of bloat (limited-use features with an aggresive
requirements level) from various interest groups that is
not strictly necessary for a protocol to be useful, and sometimes
used only by a minority.

Normally, for progression from Proposed to Draft,

   - some of the MUSTs would have to be changed to SHOULDs,
   - some of the SHOULDs would have to be changed to MAYs,
   - some parts might better be moved to seperate, optional
     extensions documents

But the particular interest groups would rather have the document
remain at Proposed than seeing any of the requirements level of
those particular features they're interested in, to come out lowered,
or see features removed from the base protocol and into a
seperate extensions document.

This is one of the reasons why there is a constant stream of new
authentication protocols.

-Martin

---

From: Mark Atwood <[email-masked]>
Date: Thu, 27 Jan 2011 23:14:35 -0800

This post would be much less confusing if you would name names, cite
examples, and point fingers.

---

From: John Leslie <[email-masked]>
Date: Fri, 28 Jan 2011 04:11:00 -0500

> examples, and point fingers.

   No, it wouldn't.

   We don't need a flame-war over which features of which protocols
would have to go away under a strict reading of RFC 2026 in order to
advance.

   The point is clear enough: that features that find their way into
Proposed Standards have constituencies, and that pulling them out is
too painful for most WGs to tackle.

> [Martin Rex <[email-masked]> wrote:] 
>

   Thank you, Martin!

   This brings us closer to the actual problem.

>> - some parts might better be moved to seperate, optional

   I've been there, done that, got the T-shirt. Some pretty dreadful
MUSTs remain because of constituencies. "Consensus" is reached only
by exhaustion.

   Often we end up leaving stuff which can reasonably be called "bloat"
(though that's not how I would describe it) because we can't reach
agreement that we can patch-in a better way without "recycling at
Proposed".

   The whole process is exhausting. More often than not, folks give up.

>> seperate extensions document.

   Remaining at Proposed just doesn't seem that bad after you've been
through the wringer a few times. (It's not that people start out
wanting to prevent progression; it's that consensus on needed changes
is too hard to reach.)

   Add to this that chartering a WG to advance from Proposed to Draft
never seems to happen (what AD would volunteer to endure this _again_?)
and we have the wrangling which should be contained in a WG arising
during IETF LastCall: few document authors will persist long enough.

   I refuse to argue how many levels there should be -- though I'd
be happy to work within the old consensus for three. What needs work
(assuming we aim for more than one) is how to get there from here!
I have some ideas; but the time just doesn't seem ripe to discuss them.

--
John Leslie <[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 30 Jan 2011 09:10:02 +1300

>    (would not help, would not hurt)

I tend to be more optimistic. I think that having only one step
ahead to reach final status is *much* less of a psychological
barrier, and the name "Internet Standard" is a *much* more appealing
target than "Draft Standard". Therefore, I believe this change will
be a significant step forward.

>       also have resulted from separate exercise of the licensing process.

I strongly agree. This exact sentence should be carried forward.

>    would help avoid this type of issue in the future

Whike I agree with Scott, I suggest solving this outside the BCP itself.
It's quite a complex issue.

>    things were not just forgotton.

Actually the draft does not appear to require interoperability testing
at all:

     "* There are a significant number of implementations with
        successful operational experience."

Is that intentional? I thought interop was generally regarded as
fundamental. So I think the text needs to be explicit about which
bits of section 4.1.2 of RFC 2026 still apply. Or expand the
sentence by adding ", including interoperation between different
implementations when meaningful."

(It's "when meaningful" because some standards such as MIB modules
don't interoperate as such, see RFC 2438.)

On another point:

"5.  Open Question Regarding STD Numbers"

IMHO the easiest solution is still what I suggested some years
ago: retain STD numbers, but assign them at the PS stage. That
removes the confusion about a PS that updates a numbered Standard.

   Brian

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 29 Jan 2011 12:52:08 -0800

>>        implementations applies to all of the options and features of the
...
> Is that intentional? I thought interop was generally regarded as

People are confusing testing with use. Those are two different kinds of 
"interoperability", with the latter being far more stringent.

The new draft specifies the latter.  And it quite intentionally does not specify 
the former.

While "testing" is extremely important for when doing development, there is no 
reason that the IETF should be required to include that very intermediary 
activity within our standards process.

So the new proposal has two phases:

    1) Specification

    2) Use

That there are intermediate real-world phases, such as development, testing and 
deployment is essential, of course.  But there is nothing essential in having 
the IETF mark completion of any of those intermediate phases.

d/
-- 

   Dave Crocker

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 30 Jan 2011 11:08:39 +1300

On 2011-01-30 09:52, Dave CROCKER wrote:
> The new draft specifies the latter.  And it quite intentionally does not
> specify the former.

Please point to the text that requires *any* kind of interoperability
being demonstrated by running code. "successful operational experience"
does not state or imply interoperation between independent implementations.

This is a big change in principle from 2026, which is not what is advertised
on the box as "primarily a reduction from three IETF standards track
maturity levels to two."

I want a two stage process, but I don't want to lose interoperability as
an explicit criterion. To me, that's always been the meaning of the
"running code" slogan.

     Brian

> 
> While "testing" is extremely important for when doing development, there
> is no reason that the IETF should be required to include that very
> intermediary activity within our standards process.
> 
> That there are intermediate real-world phases, such as development,
> testing and deployment is essential, of course.  But there is nothing
> essential in having the IETF mark completion of any of those
> intermediate phases.
> 
> d/