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

From: Yaron Sheffer <[email-masked]>
Date: Sat, 19 Jun 2010 22:48:21 +0300

In general, I think this is a good idea. It might succeed in reviving 
the notion of formal interoperability reports. A few comments though:

- Sec. 2 mentions that the criteria for Proposed Standard will not 
change. But the preceding section just described that our criteria (or 
processes) for publication are too onerous. So do we not address what's 
mentioned as a leading motivation for this change?

- I think the name "Interoperable Standard" is unfortunate. First, it's 
a mouthful. And second, it implies that whereas we didn't care about 
interoperability before, now we suddenly do. As an analogy, suppose we 
had "Proposed Standard" and "Secure Standard". Instead, I think "Full 
Standard" or "IETF Standard" would be better names. After all, people 
are looking to the IETF for standards.

- This is not to criticize the draft, but I am really wondering: at 
IPsecME we are close to publishing IKEv2-bis, and we went to great 
lengths to make it as faithful as possible to the original IKEv2 (RFC 
4306), so that implementations that are compliant don't suddenly become 
non-compliant. Suppose we were to advance this large and complex 
protocol to the 2nd maturity level, is there a manageable process to 
eliminate features from the protocol (because there are no two 
implementations that implement said features) without worrying that some 
implementations out there have become non-compliant overnight?

Thanks,
	Yaron

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 20 Jun 2010 08:10:46 +0200

Russ,

Thanks for reviving this topic.  As the YAM working group has been finding, 
trying to elevate even the most well-established and widely-used protocols to 
Full standard remains problematic.

As your Acknowledgments section cites, your proposal nicely adds to the 
considerable repertoire of variations that explore how to simplify things.

What is less clear is the model or theory or perspective that makes this 
particular variation the one to prefer.  Perhaps it does indeed offer the best 
result, but what is the basis for deciding?

The fact that few protocols have sought Draft, nevermind Full, status is a 
rather strong indication that the industry does not care about or need either. 
Absent changes in the criteria for a label and/or the process for achieving a 
second (or third) status level, what is going to motivate the community to 
behave differently?

Interoperability testing used to be an extremely substantial demonstration of 
industry interest and of meaningful learning. The resulting repair and 
streamlining of specifications was signficant.  If that's still happening, I've 
been missing the reports about lessons learned, as well as indications that 
significant protocol simplifications have resulted.  While the premise of 
streamlining specifications, based on interoperability testing, is a good one, 
where is the indication that it is (still) of interest to industry?  (I believe 
that most protocols reaching Proposed these days already have some 
implementation experience; it's still not required, but is quite common, no?)

My own proposal was to have the second status level simply take note of industry 
acceptance.  It would be a deployment and use acknowledgement, rather than a 
technical assessment.  That's not meant to lobby for it, but rather give an 
example of a criterion for the second label that is different, cheap and 
meaningful.  By contrast, history has demonstrated that Draft is expensive and 
of insufficient community interest.  We might wish otherwise, but community 
rough consensus on the point is clear.  We should listen to it.

Since your proposal is to use the existing criteria for Draft as the second 
label, why should we expect it to be more popular than it has been?

It's clear that our 3-stage model is not working.  In my view, YAM is 
demonstrating that, frankly, it's not /going/ to.  The cost is too high and the 
benefit is too low. We ought to change that because, well, the current situation 
is embarrassing.

But in making the change, there should be a fairly strong basis for believing 
that the new model will be successful.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: SM <[email-masked]>
Date: Sun, 20 Jun 2010 02:53:42 -0700

At 23:10 19-06-10, Dave CROCKER wrote:
>Thanks for reviving this topic.  As the YAM working group has been 
>finding, trying to elevate even the most well-established and 
>widely-used protocols to Full standard remains problematic.

It is problematic because there isn't any consensus on what an 
Internet Standard is and the requirements to attain that level of maturity.

In Section 2 of draft-housley-two-maturity-levels-00:

   "The requirements for Proposed Standard are unchanged; they remain
    exactly as specified in RFC 2026."

Quoting Section 4.1.1 of RFC 2026:

   "A Proposed Standard specification is generally stable, has resolved
    known design choices, is believed to be well-understood, has received
    significant community review, and appears to enjoy enough community
    interest to be considered valuable.  However, further experience
    might result in a change or even retraction of the specification
    before it advances.

    Usually, neither implementation nor operational experience is
    required for the designation of a specification as a Proposed
    Standard.  However, such experience is highly desirable, and will
    usually represent a strong argument in favor of a Proposed Standard
    designation."

The reader will note that neither implementation nor operational 
experience is required.  In practice, the IESG does "require 
implementation and/or operational experience prior to granting 
Proposed Standard status".  Implementors do not treat Proposed 
Standards as immature specifications.

This proposal removes Draft Standard and Internet Standard and 
replaces it with Interoperable Standard.  I won't quibble over the 
choice of the name yet.  In Section 5:

   'The requirement for six months between "Proposed Standard" and
    "Interoperable Standard" is removed.  If an interoperability report
    is provided with the initial protocol action request, then the
    document can be approved directly at the Interoperable Standard
    maturity level without first being approved at the Proposed Standard
    maturity level.'

What this proposal advocates is in effect having one level of 
maturity, i.e. turning the Proposed Standard into Standard".

   "In practice the annual review of Proposed Standard documents after
    two years has not taken place.  Lack of this review has not revealed
    any ill effects on the Internet Standards Process."

There seems to be a confusion between the Internet Standards Process 
and the Internet Standards Track.  An over-simplified view of the 
process is that it is about publishing RFCs.  Documents are published 
once one can get through the DISCUSSes raised by the IESG and simply 
forgotten.  As the IESG does not conduct the review of Proposed 
Standard documents, the authors are happy and the IETF Community does 
not complain as it has either forgotten or doesn't know that there 
should have been such a review.

If the IETF only needs a publishing mechanism, it could adopt this 
proposal as-is and do away with the IESG.  I'll note that the IESG is 
supposed to make its final determination known in a timely 
fashion.  The overall processing time currently is approximately 250 days.

In Section 6:

   'The current rule prohibiting "down references" is a major cause
    of stagnation in the advancement of documents.'

There isn't any current rule that prohibits "down references".  The 
reason for discouraging downward references is to have the 
specification at the same maturity level.
"Downward reference by annotation" can still be used.  That allows 
the community to balance the importance of getting a document published.

In Section 7:

   "In several situations, a Standard is obsoleted by a Proposed Standard"

A Standard is not obsoleted by a Proposed Standard.  A RFC with a 
status of Internet Standard can be obsoleted by a RFC at Proposed Standard.

In Section 8:

   "On the day these changes are published as a BCP, all existing Draft
    Standard and Standard documents automatically get reclassified as
    Interoperable Standard documents"

One of the benefits of doing this is that the IP Version 6 Addressing 
Architecture can be recognized as a "Standard" for whatever 
definition of standard this community finds suitable.

In the Acknowledgements Section:

   "In May 2010, the IESG discussed the topic at length and came to the
    conclusion that the current situation was becoming more and more
    difficult."

The current situation would certainly become more and more difficult 
if a particular charter is invoked.

This document has RFC 2606 as an Informative Reference.  That should 
at the very least be a Normative Reference.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 20 Jun 2010 14:01:11 +0200

On 20/Jun/10 11:53, SM wrote:
> implementation and/or operational experience prior to granting Proposed
> Standard status". Implementors do not treat Proposed Standards as
> immature specifications.

It seems to me that abolishing the third level is possible, now, 
because the handling of I-Ds has been enhanced.  IMHO, it is an 
advantage to require some experience before giving an I-D the rank of 
Proposed Standard.  Because I-Ds can change more rapidly and 
informally than an official standardization round, the early adoption 
phase can be much more agile that way.

However, some I-Ds become RFCs unexpectedly soon, and may ship 
untested prototypes.  If it is agreed that this is rather a shift of 
maturity levels than simply the abolishment of the last, then some of 
the current criteria for Draft Standard should be formally shifted to 
Proposed Standard accordingly.

> This proposal removes Draft Standard and Internet Standard and replaces
> it with Interoperable Standard. I won't quibble over the choice of the
> name yet.

If there are two levels and the first one is "Proposed Standard", then 
the other one ought to be "Accepted Standard", "Official Standard", or 
something that truly reflects such change (which usually does not 
affect its interoperability or security, as Yaron said.)

"Accepted Standard" would call for a somewhat better feedback from the 
community, though.

> A Standard is not obsoleted by a Proposed Standard. A RFC with a status
> of Internet Standard can be obsoleted by a RFC at Proposed Standard.

In some cases, it should be possible to replace an RFC with a reviewed 
version, at the same maturity level.  For example, the attention that 
successive SMTP documents have to pay to source routing decreases over 
time.  There is no reason why a new RFC aimed at reviewing a mature 
spec would need to reduce its maturity level, if it accomplishes the 
current requirements for third level.  I hope this point will be made 
clearer.

JM2C

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 20 Jun 2010 08:39:08 -0500

OK, we really do seem determined to relive the early 2000s...

> It seems to me that abolishing the third level is possible, now, because 
> the handling of I-Ds has been enhanced.  IMHO, it is an advantage to 
> require some experience before giving an I-D the rank of Proposed 
> Standard.  Because I-Ds can change more rapidly and informally than an 
> official standardization round, the early adoption phase can be much more 
> agile that way.
>
> However, some I-Ds become RFCs unexpectedly soon, and may ship untested 
> prototypes.  If it is agreed that this is rather a shift of maturity 
> levels than simply the abolishment of the last, then some of the current 
> criteria for Draft Standard should be formally shifted to Proposed 
> Standard accordingly.

There were proposals for Stable Snap Shots (SSS) from Scott Bradner, and 
Working Group Snapshots (WGS) from me, Dave, and Charlie Perkins. If I'm 
remembering correctly, both were intended to say "this is stable NOW, but I 
wouldn't put it in firmware, because we're still getting experience with it, 
and it could change".

Working Group Snapshots (WGS) in
http://www.watersprings.org/pub/id/draft-dawkins-pstmt-twostage-01.txt

Stable SnapShots (SSS), in
http://www.watersprings.org/pub/id/draft-bradner-ietf-stds-trk-01.txt

For extra credit, we could implement these with no 2026/2418 changes, if
changing 2026/2418 is as impossible as it looks - neither BCP says we CAN'T
do WGS/SSS.

We probably don't want to restart these discussions without someone 
summarizing the state of play in previous discussions, because Groundhog's 
Day was a great movie, but a lousy standards process :D

Thanks,

Spencer

---

From: Russ Housley <[email-masked]>
Date: Mon, 21 Jun 2010 09:39:04 -0400

> mentioned as a leading motivation for this change?

What a meant here is that the requirements in RFC 2026 for Proposed
Standard do not change.  With the opportunity for a "second bite at the
apple", I hope that the escelation that has happened over the decades
can be pushed back.

> are looking to the IETF for standards.

I am not wed to the name.  I'd prefer "Internet Standard" above the
names you suggest.

> implementations out there have become non-compliant overnight?

We have always published a "bis" RFC that removes the features.  These
RFCs ought to explain the reason for the feature removal.  Support of an
obsoleted feature does not have to make an implementation
non-conformant.   For example, "legacy" features could be documented in
an informative appendix with a warning about the consequences on
interoperability if they are supported.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 21 Jun 2010 09:43:02 -0400

Dave:

The questions that you raise will be discussed for 30 minutes at the
front of the Wednesday plenary at IETF 78.  The next step is to find out
what the community thinks about these choices.  I fully expect there to
be changes to the draft after that discussion.

As you say, we really want to see improvement, not just change.

Russ

On 6/20/2010 2:10 AM, Dave CROCKER wrote:
> particular variation the one to prefer.  Perhaps it does indeed offer
> the best result, but what is the basis for deciding?
> 
> The fact that few protocols have sought Draft, nevermind Full, status is
> a rather strong indication that the industry does not care about or need
> either. Absent changes in the criteria for a label and/or the process
> for achieving a second (or third) status level, what is going to
> motivate the community to behave differently?
> 
> Interoperability testing used to be an extremely substantial
> demonstration of industry interest and of meaningful learning. The
> resulting repair and streamlining of specifications was signficant.  If
> that's still happening, I've been missing the reports about lessons
> learned, as well as indications that significant protocol
> simplifications have resulted.  While the premise of streamlining
> specifications, based on interoperability testing, is a good one, where
> is the indication that it is (still) of interest to industry?  (I
> believe that most protocols reaching Proposed these days already have
> some implementation experience; it's still not required, but is quite
> common, no?)
> 
> My own proposal was to have the second status level simply take note of
> industry acceptance.  It would be a deployment and use acknowledgement,
> rather than a technical assessment.  That's not meant to lobby for it,
> but rather give an example of a criterion for the second label that is
> different, cheap and meaningful.  By contrast, history has demonstrated
> that Draft is expensive and of insufficient community interest.  We
> might wish otherwise, but community rough consensus on the point is
> clear.  We should listen to it.
> 
> Since your proposal is to use the existing criteria for Draft as the
> second label, why should we expect it to be more popular than it has been?
> 
> demonstrating that, frankly, it's not /going/ to.  The cost is too high
> and the benefit is too low. We ought to change that because, well, the
> current situation is embarrassing.
> 
> But in making the change, there should be a fairly strong basis for
> believing that the new model will be successful.
> 
> d/

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 21 Jun 2010 11:30:36 -0400

Russ
I strongly support this approach.
In particular I think the downward ref relaxation is of great value as 
chair of WG with with 30+ RFC's at PS and advancing them in order or 
RFC's up the standards track vs. advancing the ones that are important 
will hopefully be the happy consequence of a change like this.

	Olafur

On 21/06/2010 9:39 AM, Russ Housley wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>
>
>

---

From: Martin Rex <[email-masked]>
Date: Mon, 21 Jun 2010 17:45:09 +0200 (MEST)

Dave CROCKER wrote:
> 
> Interoperability testing used to be an extremely substantial demonstration
> of industry interest and of meaningful learning. The resulting repair and 
> streamlining of specifications was signficant.  If that's still happening,
> I've been missing the reports about lessons learned, as well as
> indications that significant protocol simplifications have resulted.
> While the premise of streamlining specifications, based on
> interoperability testing, is a good one, where is the indication that
> it is (still) of interest to industry?  (I believe that most protocols
> reaching Proposed these days already have some implementation
> experience; it's still not required, but is quite common, no?)
> 
> that Draft is expensive and of insufficient community interest.
> We might wish otherwise, but community rough consensus on the point
> is clear.  We should listen to it.

I would prefer if the IETF retains the third level and puts an emphasis
on cutting down on protocol feature bloat when going from draft to
full standard.

What I see happening is that Proposed Standards often start out with
a lot of (unnecessary) features, and some of them even inappropriately
labelled as "MUST implement".

The draft standard only does some interop testing on a small number
of implementations, not unlikely those participating the standardization
process.  It neither addresses what subset other implementations implement
and what subset is actually necessary for the general use case in the
installed base.

One of the worst feature bloat examples is PKIX.

It contains an awkward huge number of features that a number of
implementations do not support -- and work happily without.
There should either be a split of e.g. 5280 into a "basic profile"
and a "advanced feature profile", or the status for some of the
extensions should be fixed from "MUST implement" to "SHOULD implement"
to match the real world and real necessity.

-Martin

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 Jun 2010 09:57:21 -0600

On 6/20/10 6:01 AM, Alessandro Vesely wrote:
> something that truly reflects such change (which usually does not affect
> its interoperability or security, as Yaron said.)

Here's an idea:

1. The first level is simply "Request for Comments".

Once an RFC is published, we start to gather comments. Naturally, we
need to write a process document that specifies in greater detail the
kinds of comments we are requesting -- i.e., regarding implementation,
deployment (the real meaning of "running code"), security as observed in
the real world, manageability, etc.

2. The second level is "Internet Standard".

Once we have gathered comments, we go through a "bis" process to
incorporate all of that feedback into an improved specification. We
obsolete the original Request for Comments and go on with our lives. We
still accept comments (errata etc.) about the Standard, but don't make
any substantive changes to it (unless we rev the protocol version).

Peter

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

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 20 Jun 2010 16:41:11 +0200

On 6/20/2010 11:53 AM, SM wrote:
> Standard status".

Well, they do not /always/ require it.

That said, the fact that they often do and that we've lived with the reality of 
that for a long time could make it interesting to simplify things significantly:

    1.  Have the current requirements for Draft be the entry-level requirement 
for a standard  -- do away with Proposed, not Draft.

    2.  Have a clear demonstration of industry acceptance (deployment and use) 
be the criterion for "Internet Standard" (ie, Full.)

Having two interoperable implementations required for /all/ new specifications 
takes care of two interesting questions.

       a.  Whether the specification can be at all understood.

       b.  Whether there is any meaningful industry motivation to
           care about the work.

With these two questions satisfied, the nature of challenges against 
standardization might tend to be more pragmatic than theoretical.

d/

-- 

   Dave Crocker

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 21 Jun 2010 13:12:41 -0400

On 2010-06-20 10:41, Dave CROCKER wrote:
> That said, the fact that they often do and that we've lived with the 
> reality of that for a long time could make it interesting to simplify 
> things significantly:
>
>    1.  Have the current requirements for Draft be the entry-level 
> requirement for a standard  -- do away with Proposed, not Draft.
>
>    2.  Have a clear demonstration of industry acceptance (deployment 
> and use) be the criterion for "Internet Standard" (ie, Full.)
>
> Having two interoperable implementations required for /all/ new 
> specifications takes care of two interesting questions.
>
I strongly support this approach.  The main drawback of this would be 
that a document would sometimes need to exist for longer as an I-D while 
implementations are developed, but balancing that is the fact that those 
implementations would then inform the first RFC version rather than some 
subsequent update, and it would be harder to get an RFC published for 
something no one is really going to build.

---

From: John Leslie <[email-masked]>
Date: Mon, 21 Jun 2010 13:46:11 -0400

>> implementation and/or operational experience prior to granting Proposed

   That's news to me: I can't recall any recent discusses calling for
operational experience before publishing as Proposed Standard.

   Some years ago, there was such a requirement for Routing Area, but
that was declared obsolete. (In actuality, there seems to still be a
somewhat informal requirement to document implementations for _some_
Routing Area documents, but it is not by IESG direction.)

> Well, they do not /always/ require it.

   I'm willing to be corrected: does anyone want to document a single
case where this was required _by_the_IESG_ in the last two years?

>     requirement for a standard  -- do away with Proposed, not Draft.

   That strikes me as a terrible idea.

   I can think of several cases where WG LastCall was postponed until
two implementations were demonstrated.

   By that time, folks were so set on their implementations that it
proved "just too difficult" to dislodge that with facts about faults
in the specification.

   (I realize that only flame-wars can follow such a statement as
"the reason" to keep 2026 the way it is for Proposed Standard. I
shall try to find a sufficiently flame-proof suit...)

   Please consider human nature here. We do have folks that are good
at pointing out theoretical weaknesses of proposed algorithms. But
they stand no chance of prevailing against "running code" that's
already deployed in the field.

   I grant that IETF runs on "rough consensus and running code"; and
I have no particular interest in even _trying_ to change that.

   But can't we PLEASE keep the review stage before we cast the
"running code" in silicon?

> 2.  Have a clear demonstration of industry acceptance (deployment and 
>     use) be the criterion for "Internet Standard" (ie, Full.)

   In truth, there are interlocking reasons why advancement beyond
Proposed Standard is so difficult -- but I'd like to call attention
to one particular reason: the IESG is overworked.

   Look at any bi-weekly agenda.

   Count the pages in the I-Ds.

   Glance through some of the questions raised. Even if you think
the majority of them are spurious, documents _do_ reach the IESG
in a state which essentially precludes implementation working only
from the document.

   Now, imagine bringing every standard-track document back two more
times. :^(

   We've had several Working Groups over the years consider this;
and IMHO they've mostly agreed the IESG shouldn't have to act on
these documents three times.

   But we don't have to abolish the three-levels of 2026 to accomplish
that: there have been several proposals to simplify the process of
advancement.

   It is a characteristic of consensus process that sometimes it's
"obvious" to a majority that the "wrong consensus" was reached.

   That doesn't mean, however, that proposing a "better consensus"
is workable. We've gone through years of proposing "better consensus"
here; and I'm frankly not convinced it's worth another half hour of
Plenary time to propose another.

   We have three levels in RFC 2026. The levels are reasonable,
starting with a clear specification, progressing through interoperable
implementation, and finishing with experience in the field.

   Frankly, the fact that we seldom get past the first _doesn't_
convince me there's anything wrong with the levels. And I don't see
why we should expect it to convince anyone who doesn't already
subscribe to one or another "better consensus".

   I wish we could instead discuss how to improve the _process_ of
advancing through the levels. It may be that some prior IESG was
unwilling to let go of a death-grip on blocking advancement for any
perceived imperfection. (I simply don't know...)

   I do NOT believe, however, that the current IESG has any such
interest in keeping tight control of advancement.

--
John Leslie <[email-masked]>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Jun 2010 10:47:25 -0700

At 1:12 PM -0400 6/21/10, Scott Lawrence wrote:
>>That said, the fact that they often do and that we've lived with the reality of that for a long time could make it interesting to simplify things significantly:
>>
>>   1.  Have the current requirements for Draft be the entry-level requirement for a standard  -- do away with Proposed, not Draft.
>>
>>   2.  Have a clear demonstration of industry acceptance (deployment and use) be the criterion for "Internet Standard" (ie, Full.)
>>
>>Having two interoperable implementations required for /all/ new specifications takes care of two interesting questions.
>>
>>With these two questions satisfied, the nature of challenges against standardization might tend to be more pragmatic than theoretical.
>I strongly support this approach.  The main drawback of this would be that a document would sometimes need to exist for longer as an I-D while implementations are developed, but balancing that is the fact that those implementations would then inform the first RFC version rather than some subsequent update, and it would be harder to get an RFC published for something no one is really going to build.

It would only be harder to get a standards track RFC published for something no one is really going to build: there will still be Experimental and Informational RFCs.

Such a change would put an new and interesting set of pressures on WGs, and on individuals who go through the individual submission process for standards track. It is well worth considering.

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael StJohns <[email-masked]>
Date: Mon, 21 Jun 2010 16:33:13 -0400

I think its a good idea to readdress this.  Part of the issue with the current system, is that there is both no great benefit to advancing a standard to the next level for the advocates, and no real downside to not advancing it.  In many cases, having gone through the pain of getting to RFC status, one is unwilling to place their body in the firing line again.  Any change to the system should consider the real world implications and try and add in the appropriate carrots and sticks.

One side note - MIBs.  MIBs by their nature are actually collections of mini-standards - the objects.  Once an object is defined and published in a non-transitional document (RFC), the OID associated with that object is pretty much stuck with that definition.  And that permanance tends to percolate up to the collection of objects that make up a MIB.  

I'd suggest only a single standards level for a MIB - stable - tied to a specific conformance statement.  Obviously, this is sort of a sketch of an idea, but given the immutability of each MIB object, advancing a MIB is pretty much impossible unless there are absolutely no changes.

Mike

---

From: Ross Callon <[email-masked]>
Date: Mon, 21 Jun 2010 20:55:04 -0400

The only thing that I disagree with in the draft is the term "interoperable standard". Looking at each change in a bit more detail: 

 - Two levels of standards rather than three:  
I strongly support this. It is pretty clear that in most cases people don't bother with the effort to move past Proposed Standard. The different between "proposed" and "draft" seems too small to be worth the trouble. If there was only one step required after "proposed", then people *might* bother to do it. Moving to two steps instead of three is therefore a step in the right direction (and IMHO a smaller step that is clearly in the right direction is usually preferred to a larger step that might or might not be in the right direction). 

 - Calling the second (more mature) step "Interoperable Standard":  
I don't like this, for the simple reason that it makes it sound as if "proposed standard" might not be interoperable. In practice there are lots of proposed standard documents that are widely deployed in multi-vendor networks, and interoperate just fine (in many cases multi-vendor deployment begins well before the document is submitted for publication as a proposed standard). I prefer the term "internet standard" that some others have proposed, or "full standard" would be fine also. 

 - Removing the requirement for a six month wait between "proposed standard" and the next step: 
I don't have an opinion on this.

 - Removing the required review of proposed standards every two years: Support. Given that we have never done this, it seems like a very good idea to write the rules to match reality. 

 - Allowing Downward References (from "internet standard" to "proposed standard):
Support. I can recall lots of cases where downward references resulted in slowing down document publication, required second (or third) IETF last calls, and caused more work for Area Directors (and/or WG chairs and authors). I can't think of any cases where restricting downrefs actually helped, nor caused anyone to respond to the extra IETF last call on the issue. 

 - Abolishing STD numbers:
Support. 

 - Transition to new scheme: All existing "draft" and "full" standards get moved to the new more mature standards level.
Support. 

Russ, thanks for putting this together. 

Ross

---

From: SM <[email-masked]>
Date: Tue, 22 Jun 2010 00:05:29 -0700

At 05:01 20-06-10, Alessandro Vesely wrote:
>pay to source routing decreases over time.  There is no reason why a 
>new RFC aimed at reviewing a mature spec would need to reduce its 
>maturity level, if it accomplishes the current requirements for 
>third level.  I hope this point will be made clearer.

In theory, major clean-ups are done for the Draft Standard.  The 
third level is about significant implementation and successful 
operational experience.  There is no reduction in maturity level for 
a clean-up.

>Well, they do not /always/ require it.

It's an unpublished guideline followed by authors to enter the 
publication loop.

>reality of that for a long time could make it interesting to 
>simplify things significantly:
>
>    2.  Have a clear demonstration of industry acceptance 
> (deployment and use) be the criterion for "Internet Standard" (ie, Full.)

What should be done if there isn't significant deployment and use?

>on cutting down on protocol feature bloat when going from draft to

That could be added as a requirement.  It may turn into a significant 
effort and produce the same results as the current situation.

>1. The first level is simply "Request for Comments".

That would not fit as an intended status.

>operational experience before publishing as Proposed Standard.

It's an expectation that the authors have accepted and not a DISCUSS topic.

>    Count the pages in the I-Ds.

Yes, they do end up getting a lot of work.

>in a state which essentially precludes implementation working only

Yes.

At 11:09 21-06-10, Bernard Aboba wrote:
>So perhaps the hierarchy should be:
>
>a.       Experimental.

"Experimental" could be used to get a stable version published.  Does 
the fact that there are more "Proposed Standard" RFCs compared to 
"Experimental" RFCs suggest anything?

Regards,
-sm

---

From: Yoav Nir <[email-masked]>
Date: Tue, 22 Jun 2010 10:51:55 +0300

I don't think I agree with this.

> on cutting down on protocol feature bloat when going from draft to

You want to be very careful cutting down on feature bloat. Some people may be using those features you consider "bloat". The right time to cut down on bloat is before publication of the original RFC. That's when it gets the most scrutiny, and that's the time to tell the author(s) that certain features should either clearly be OPTIONAL (aka MAY), or cut out entirely and placed in an extension document that may or may not later be advanced in maturity level.

> labelled as "MUST implement".

Perhaps this should explicitly be part of the review process. Think of a minimal implementation, and make sure all the features it doesn't need are optional

> and what subset is actually necessary for the general use case in the

The small group of those participating in the standardization process doesn't necessarily change later. Even if more implementers have joined the fray, they don't necessarily come to the IETF. Their "contribution" is only reflected in "horror stories" from the same implementers of the original standard.

With the TLS renegotiation thing late last year, some people thought that five leading implementations were responsible for almost all of TLS. It later turned out that there were dozens of implementations in active use. And yet, most of these implementers either don't participate in the TLS WG, or don't identify as such. I had no idea SAP had their own TLS implementation, although you had participated in the TLS WG for a while, and I have never said anything about Check Point's TLS implementation.

> to match the real world and real necessity.

I don't like SHOULDs that only a small subset implement. Advanced features beyond the basic profile should not be an all-or-nothing thing like an "advanced feature profile" implies.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 22 Jun 2010 10:12:13 +0200

Russ,

Thank you for bringing this topic full circle.  Having considered this
topic for a long time, and having lead a cleanup around old standards in
newtrk, I share the following thoughts for your consideration.

In concurring in part with what Bernard and Mike wrote, the basic
question I ask, in several parts, is whether standards maturity levels
have been overtaken by events or time?  For each level above PS, a
substantial amount of work must go into advancement, perhaps without a
single line of code actually being written or changed by implementers. 
This then leads to a question of motivations.  What are the motivations
for the IESG, the IETF, and for individual implementers?  Traditionally
for the IETF and IESG, the motivation was meant to be a signal to the
market that a standard won't change out from underneath the developer.

Question #1: Is such a signal needed today?  If we look at the 1694
Proposed Standards, are we seeing a lack of implementation due to lack
of stability?  I would claim that there are quite a number of examples
to the contrary (but see below).

Question #2: Is the signal actually accurate?  Is there any reason for a
developer to believe that the day after a "mature" standard is
announced, a new Internet Draft won't in some way obsolete that work? 
What does history say about this effort? 

Question #3: What does such a signal say to the IETF?  I know of at
least one case where work was not permitted in the IETF precisely
because a FULL STANDARD was said to need soak time.  It was SNMP, and
the work that was not permitted at the time was what would later become
ISMS.

Question #4:  Is there a market advantage gained by an implementer
working to advance a specification's maturity?  If there is none, then
why would an implementer participate?  If there *is* a market advantage,
is that something a standards organization wants?  Might ossification of
a standard retard innovation by discouraging extensions or changes?

Question #5:  Are these the correct questions, and are there others that
should be asked?

I do not mean to answer these research questions here, but I claim that
that they should be answered, perhaps with some academic rigor, and may
be a worth subject for the economics and policy research group that
Aaron is considering.

Referring to SM's and Dave's messages, judging maturity based on
industry-wide acceptance requires a similar analysis, but with an added
twist: the grey areas of industry acceptance make these sorts of
decisions for the IESG rather difficult.  Having gone through the
effort, it was clear to me that there have been some losers, and I think
we can all spot some winners that remain at Proposed.

Eliot

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Jun 2010 11:16:30 -0400

> to the contrary (but see below).

In connection with that question, I'll observe that a very large
number of the DNS protocol documents have not advanced along the
standards track, and efforts to do something about that state of
affairs have not been very successful.  In addition, any time there is
an effort to make a change to anything already deployed is met by
arguments that we shouldn't change the protocol in even the slightest
detail, because of all the deployed code.  (I've been known to make
that argument myself.) 

I don't know whether the DNS is special in this regard, though I have
doubts.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Jun 2010 13:20:43 -0400

In reply to a number of different threads:

* This proposal, however flawed some might think it is is certainly a much
better description of current practice than the process document.

It is a fact that almost every 'IETF Standard' of any consequence was
developed before the first meeting of the IETF. Meanwhile the most
consequential IETF Protocol developed since is not an IETF standard. Except
for MIBs, the only protocol documents that have achieved standard status
have done so by being grandfathered.

My principle criticism of the existing process has always been that the IESG
has been unwilling to either apply it as written or change the description
to meet the practice.

* The reluctance to spend time on progression to DRAFT status is not
significant.

There is no way that I could justify the time and expense required to
progress a spec from Proposed to Draft as matters stand because it is a
mid-point to a destination I do not expect to reach. There is really no
audience in which the distinction between proposed and draft is going to
encourage adoption of a specification.

I would not expect every Internet spec to go through the full process
though. In fact there would be little point if they did. I would expect most
Internet specs to stop at stage 1 and only foundational specs would go to
stage 2 and then only if they had been successful.

For example, TLS and PKIX are clearly very successful and foundational.
Stuff gets built on them both all the time. DKIM on the other hand is not
foundational in the same way. At least not at present. And many of the
design decisions taken in DKIM were made for reasons of expediency and not
necessarily something you would want to see copied.

If people do start using the DKIM approach as foundational for other specs
then we really should go back and revisit some of the design decisions and
progress the spec to the next level. Otherwise there is no point.

Another similar example is DNSSEC, which is not going to be a real standard
until it is deployed and being used to actually reject traffic. Any proposal
of any real consequence is going to have to change during deployment (if
deployment succeeds). So having two stages makes sense to capture the
descriptions before and after.

* Current Proposed is actually the original requirement for draft

If you look at current practice, there is in fact usually a third stage only
it occurs before the Proposed RFC is published. In the old days it was
acceptable to throw some ideas together and slap out a 'proposed' RFC at an
early stage of development. In the old days RFC stood for Request For
Comments.

Today that step usually takes place outside the IETF or in Internet-drafts.
In fact it is usually encouraged for a group of proposers to have developed
something and have a writeup before going for a BOF. Such documents
frequently end up as 'informational'.

Current requirements for publishing a Proposed Standard are considerably
higher than they were for a draft standard.

* Down References do not cause harm

The only criteria for accepting a reference should be that the description
is sufficiently accessible and sufficiently well defined to enable
interoperable implementations.

I don't think it helped matters in the slightest to delay the publication of
specs depending on PKIX while PKIX was revised to draft standard. The parts
of SMIME and TLS that depended on PKIX were not the parts that were blocking
the progress of PKIX.

Similarly, there should be some language in there to point out that a
reference to a 50 year old expired patent is not a reason to object to a
standards proposal. Referencing a patent does not change the liability
incurred in the slightest. If the patent is enforceable it will apply
whether cited in the text or not. The reason to avoid references to patents
is that patents do not usually have a sufficiently specific description of
the process to be implementable without ambiguity.

* Internet Standard status should require periodic review

I think it is pretty obvious that the Internet mail standard is not the one
described in RFC821 and RFC822. It is even pretty obvious that you need to
know and implement more than RFC2821 and RFC2822 if you want to get mail to
arrive successfully.

Achieving standards status should not be the end of the matter.

Rather than having a third stage in the standards process I would like to
see a periodic examination of standards to see if what they describe is a
sufficiently complete description of reality.

Any worthwhile standard is going to evolve or die. Today NNTP and FTP are
still in the canon. But further development is clearly impossible, they are
both overtaken by events.

PKIX is going to remain relevant for some decades yet. But it will grow and
change and as it does some parts will need some pruning.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 21 Jun 2010 19:44:07 +0200

> on cutting down on protocol feature bloat when going from draft to

OK.  All you need is to develop an IETF rough consensus in support of that change.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 21 Jun 2010 19:46:33 +0200

On 6/21/2010 5:57 PM, Peter Saint-Andre wrote:
> Once an RFC is published, we start to gather comments.

Peter,

How is that different from an Internet Draft?

d/
-- 

   Dave Crocker

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Jun 2010 14:00:21 -0400

I disagree.

For changes such as DNSSEC there is no way to move as many parts of the
industry as need to be involved with an Internet draft. Microsoft is not
going to implement a draft in Windows Server, neither is Apple.

Operational experience in this case means at a minimum taking two conformant
DNS servers and having them exchange messages successfully. But that is
several orders of magnitude less than Internet wide deployment.

But anyone who knows PKI and looks at the current specs knows that what is
described there is not sufficient to deploy on. No liability model for a
start. And the assumption that a new form of PKI is going to suddenly deploy
in three weeks time using a technology base entirely different from
X.509v3/PKIX without any concurrence between the two is interesting to say
the least.

So when an infrastructure change is being proposed there has to be a
starting point for a technical discussion that has a pretty high degree of
buy-in, even though the ultimate shape of the infrastructure is unknowable
at that point. Most of what is finally deployed as DNSSEC will look like the
current proposal. But there will be important differences and those need to
be captured.

On Sun, Jun 20, 2010 at 10:41 AM, Dave CROCKER <[email-masked]> wrote:

> reality of that for a long time could make it interesting to simplify things
> significantly:
>

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

---

From: "Polk, William T." <[email-masked]>
Date: Mon, 21 Jun 2010 16:12:49 -0400

> something no one is really going to build.

On first blush, I like this approach (doing away with Proposed rather than
Draft) as well, although I see rather different process implications.

In many ways, this still supports a three step maturity level. If two
independent implementations are not available, then the I-D can still be
submitted for publication as an Informational RFC (or Experimental).  Once
two implementations are available, the document could be resubmitted for
Draft Standard.  

This is still better than the current three step process for a number of
reasons: 
(1) the line between proposed standard and informational rfc is often
blurry, but the difference between informational and draft standard is
relatively clear; 
(2) there is no way to differentiate between a proposed standard with lots
of supporting code, and one that has little implementation support, but
neither is likely to be progressed to draft these days; and
(3) a streamlined two-step maturity process is available to specifications
that have significant support.

Tim

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Jun 2010 19:57:19 -0400

Another thing to consider here is the point at which code points are
assigned.

In a lot of cases we have had incompatibility resulting from experimental
code points being used and then changed when the final draft is agreed.

For some spaces code points are scarce and it is necessary to conserve. But
for most there is no real harm done by wasting a few. And in the case of
OIDs and URIs the code space is infinite.

On Mon, Jun 21, 2010 at 4:33 PM, Michael StJohns <[email-masked]>wrote:

> I think its a good idea to readdress this.  Part of the issue with the
> current system, is that there is both no great benefit to advancing a
> standard to the next level for the advocates, and no real downside to not
> advancing it.  In many cases, having gone through the pain of getting to RFC
> status, one is unwilling to place their body in the firing line again.  Any
> change to the system should consider the real world implications and try and
> add in the appropriate carrots and sticks.
>
> One side note - MIBs.  MIBs by their nature are actually collections of
> mini-standards - the objects.  Once an object is defined and published in a
> non-transitional document (RFC), the OID associated with that object is
> pretty much stuck with that definition.  And that permanance tends to
> percolate up to the collection of objects that make up a MIB.
>
> I'd suggest only a single standards level for a MIB - stable - tied to a
> specific conformance statement.  Obviously, this is sort of a sketch of an
> idea, but given the immutability of each MIB object, advancing a MIB is
> pretty much impossible unless there are absolutely no changes.
>
> Mike
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Jun 2010 08:13:03 -0400

Feature 'bloat' in PKIX is largely due to the fact that the features have
already been accepted in the ITU version of the spec that is being profiled.

But the other reason is that the original PKIX core did not cover the full
set of requirements and that these were added as additional protocols
instead.

If you start from a clean slate, as I had the luxury of doing with the work
that led to XKMS and the SAML assertion infrastructure, you can implement
the whole of PKIX in a core spec of about twenty pages (not including
examples, schemas, etc).

The basic problem in PKIX is not feature bloat, it is the opposite. When
OCSP was proposed people bid the feature set down to the absolute minimum
core. So SCVP was a separate protocol and not an integral part of OCSP as
would have been my approach. And despite each being more complex than XKMS,
SCVP and OCSP combined provide less functionality than XKMS/XKISS.

That is not due to better designers, it is due to being able to look at the
totality of the requirements at once rather than discovering them on the
way.

If you look at a certificate, a crl and an OCSP response you will note that
all three share a set of core properties but they are different entities in
PKIX because they were designed as such. If you have the luxury of a
redesign you can make something simpler. But the only way to slim the spec
down otherwise is to hack out chunks of the spec that people are using - or
at least are going to say they are using.

I can't see anything good coming from an attempt to slim down specs after
PROPOSED. Unless the decision to deprecate a set of functionality is
genuinely uncontroversial there is going to be a faction looking to protect
their code. And IETF process gives them an endless series of opportunities
to do so. Some DNSSEC folk spent four years and then another three years
resisting two changes to their spec that were asserted to be absolutely
necessary to make deployment possible. Trying to remove functionality at
stage three because some people felt the problem should have a simpler
solution is a recipe for paralysis and a huge amount of make-work that will
probably never result in a single feature being deleted.

Take PKIX policy constraints for example. 99% of all Internet applications
would work just fine without any of that code. But there is one very
specific party that has rather a lot of code that is based on the premise
that the code will be there. And nobody can know whether my 99% guess is
accurate or not, it might be 90% or I might be completely wrong and everyone
uses that feature. The point is that nobody is going to know for sure what
people have built on top of a protocol expecting some proposed feature to
stay in the spec. There could be absolutely nobody out there actually using
that stuff in a real application and it would be almost impossible to
distinguish that case from 'almost nobody'. How do you prove a negative?

In short the reason a lot of specs are too complex is not that they try to
do too much. It is the opposite, the original spec did not have enough
functionality and adding this functionality as extensions led to a more
complex result than could have been achieved with a larger set of initial
requirements.

On Mon, Jun 21, 2010 at 11:45 AM, Martin Rex <[email-masked]> wrote:

> demonstration

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Jun 2010 00:37:23 -0400

I agree with these comments, and I'll tackle them in -01 of the draft.

Russ

On 6/20/2010 5:53 AM, SM wrote:
> reason for discouraging downward references is to have the specification
> at the same maturity level.
> "Downward reference by annotation" can still be used.  That allows the
> community to balance the importance of getting a document published.
> 
> In Section 7:
> 
> Architecture can be recognized as a "Standard" for whatever definition
> of standard this community finds suitable.
> 
> This document has RFC 2606 as an Informative Reference.  That should at
> the very least be a Normative Reference.

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Jun 2010 00:40:25 -0400

We often replace a Proposed Standard with an updated document that
remains at the Proposed Standard maturity level.  There does not seem to
be confusion when this happens.

Russ

On 6/20/2010 8:01 AM, Alessandro Vesely wrote:
> time.  There is no reason why a new RFC aimed at reviewing a mature spec
> would need to reduce its maturity level, if it accomplishes the current
> requirements for third level.  I hope this point will be made clearer.

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Jun 2010 00:48:04 -0400

> something no one is really going to build.

This would seem to encourage publication as Informational (perhaps on
the Independent Submission Stream) as a first step.  I'm not sure that
really reduces the work load, but it does shift it out of the standards
track.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Jun 2010 00:53:22 -0400

> case where this was required _by_the_IESG_ in the last two years?

I only know of one case where it was even discussed.  The IESG felt that
it was necessary to tell the WG that such a requirement was needed in
their charter.  Since that was not the case, the discussion was abandoned.

The IESG concluded that it could require interoperability testing in the
future only if the WG was warned ahead of time by including the
requirement in their charter.

Russ

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Jun 2010 16:29:55 +0300

John,

> Routing Area documents, but it is not by IESG direction.)

AFAICT the IESG is not setting any requirements like this. We are 
careful about documents stating correctly what their limitations or not 
so well understood areas are. And sometimes a working group may decide 
that they do not want to forward a document for publication until it has 
some operational experience. But as a general rule the IESG is not 
demanding this.

I don't want to say that we would never do it for any document, however. 
I remember a recent case were one AD wanted operational experience on a 
new, relatively complex design. Other ADs pushed back and the document 
was approved without that experience. However, there might be cases 
where we should have that experience. One case that comes to mind is 
draft-ietf-intarea-ipv4-unique-id which among other things does an 
Update: 791 and we would never do that without years of very widespread 
experience.

In short: its a judgment call but generally speaking the IESG does not 
require operational experience for PS.

Jari

---

From: Scott Lawrence <[email-masked]>
Date: Fri, 25 Jun 2010 10:58:14 -0400

Scott Lawrence wrote:
>>   The main drawback of this would be
On 2010-06-23 0:48, Russ Housley wrote:
> track
I think that Experimental would be more appropriate, but (and I hate to 
bring this into it yet again because I agree that what Russ has 
suggested is a useful step and that we should not make the perfect the 
enemy of the better), I think that there is a more fundamental 'brand 
management' issue here that just must be faced:

Hardy anyone not active in the IETF (and apparently some who are) 
understands that there is a difference between the various document 
types (Informational, Experimental, Historical, and the different 
flavors of Standard Track) within the RFC series.  Product managers and 
customers rarely ask 'is this standards track in the IETF?'; they ask 
'is there an RFC for this?'.

I think that a different numbering series needs to be created so that 
'RFC' means what most people (incorrectly) think that it means now: that 
something is a standard that has passed the IETF review and approval 
process.  Only standards track documents should get an RFC number, and 
all others (Informational, Experimental, Historic, and any other 
archival documents we invent that are not standards track) should get 
numbers in this new series (IAP - Internet Archived Publication ?) 
instead.  Yes, I know that the 'STD' and/or 'BCP' numbering schemes were 
supposed to do something of this kind, but they are 1) not understood at 
all outside the IETF, and 2) not really archival, since what they point 
to can change (which from an implementation and conformance point of 
view actually makes them less useful, I think).

Many people don't even make a distinction between an I-D and an RFC, 
despite the plain boilerplate text in every I-D that explains it; once 
upon a time, the fact that an I-D disappeared helped, but the web and 
search engines demolished the practical difficulty of that years ago.  
This argues that making the distinction I suggest may be futile, but I 
still think that it's important.

There are a lot of people out there that think 'RFC' means something 
that it actually does not, and I think we have established that we can't 
change this misconception, so I think we should just agree that from now 
on that's what it means, and create one or more new labels to mean other 
things.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jun 2010 15:01:45 -0400

I can't remember offhand if DNS got to full standard or not, lets say for
the sake of argument that it did.

If we want to make a significant change to DNS, such as yank out some
features that were never used, we have a minimum of about six years before
the change can be made.

First we would have to get an ID written and progress it through the working
group, that would be two years. Then we would have to get the proposed
standard to draft, a minimum of two years. Then we would have to go from
draft to standard, which has not happened to a DNS spec since the fall of
the Soviet Union.

We currently have the idiotic position where RFC821 is a full standard and
RFC2821 which obsoletes it is not.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 25 Jun 2010 23:35:25 +0300

On Thursday, June 24, 2010 22:01 Phillip Hallam-Baker wrote:

<snip/>
> We currently have the idiotic position where RFC821 is a full standard and RFC2821 which obsoletes it is not.

Why is this idiotic. RFC 821 needed to be obsoleted. It had some features that needed to be removed, and some things that may have been appropriate in 1982, but no longer so in 2001. "Proposed", "Draft" and "Full" refer to the maturity of a standard, not to how well it fits the current Internet. One could argue that 821 was very mature, because it needed a revision only after 19 years.

Just because the old standard needs replacing, does not automatically mean that the new standard is just as mature as the old one.

It does, however mean that the distinction is meaningless to implementers. In 2001 or 2002 we would expect someone implementing SMTP to implement 2821, a proposed standard, rather than 821, a full standard. While implementing a full standard gives you more assurance about the quality of the spec, it doesn't mean that "they" are not going to obsolete it ever.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 27 Jun 2010 10:36:07 +0300

On Jun 26, 2010, at 12:56 AM, Phillip Hallam-Baker wrote:

> The fact remains that RFC 821 has the STANDARD imprimatur and the better specification that was intended to replace it does not.

Yes, but most of the RFC repositories, including http://tools.ietf.org/html/rfc821 show "Obsoleted by: 2821" right there at the top next to the word "STANDARD". Anyone looking at this RFC now (as opposed to 10 years ago) would immediately know that while this *was* a standard, it is now obsolete.

This raises another question. What does "obsolete" mean?  RFC 821 and RFC 2821 describe the same standard. Upgrading implementations to comply with RFC 2821 was not supposed to break any connectivity. They describe the same protocol, so unless you are interoperating with a peer that implemented some deprecated features, you're good. OTOH, looking at RFC 2409, it says that RFC 4306 obsoletes it. But RFC 2409 is IKEv1, while RFC 4306 is IKEv2.  If you had upgraded an implementation to comply with RFC 4306 *instead of* RFC 2409 in 2005, you would not be able to finish an IKE exchange at all. If you need to implement IKEv1 (that is still much more widely used than IKEv2), the RFC to look at is 2409, not 4306.  IMO this is a totally different meaning of "obsolete"

> It seems pretty basic to me that when you declare a document Obsolete it should lose its STANDARD status. But under the current system that does not happen.

It's true that under the current system RFCs never change. Even advancing them to a higher level gives them a different number.

> This situation has gone on now for 15 years. Why would anyone bother to put time an effort into progressing documents along the three step track when most of the documents at the highest rank are actually obsolete?

I don't think there's any incentive to do so.  RFC 4478 has been at "Experimental" for 4 years, with at least 3 independent implementations. But when I thought it was time to advance it to PS, I was told (by an AD) "why bother?". It certainly didn't stop implementers from implementing it.

Also, it seems that in the last 4 years, the IETF has published only 3 full standards, 18 draft standards, and 740 proposed standards. I think this tells us that there is very little incentive for advancing a standard.
http://www.rfc-editor.org/std-index.html
http://www.rfc-editor.org/fyi-index.html

> What does STANDARD actually mean if the document it refers to is quite likely obsolete?

---

From: SM <[email-masked]>
Date: Sun, 27 Jun 2010 10:32:01 -0700

Hi Yoav,
At 00:36 27-06-10, Yoav Nir wrote:
>Yes, but most of the RFC repositories, including 
>http://tools.ietf.org/html/rfc821 show "Obsoleted by: 2821" right 
>there at the top next to the word "STANDARD". Anyone looking

Yes.

>at this RFC now (as opposed to 10 years ago) would immediately know 
>that while this *was* a standard, it is now obsolete.

If you then go to RFC 2821 and you will see that it is a Proposed 
Standard which has been obsoleted by RFC 5321 (Draft 
Standard).  There are implementations out there that are STD 10 
compliant.  There are still a lot of implementations out there that 
are RFC 2821 compliant.  I'll ignore the differences between these 
specifications.  Most people mention RFC 2821 when it comes to 
SMTP.  Do I implement RFC 2821 or RFC 5321?

Let's try another example.  RFC 4871 was published in May 2007 as 
Proposed Standard.  It was updated by RFC 5672 in August 2009.  Do I 
want to implement a specification that could be changed in two years 
or do I stick to the Draft or Internet Standard for maturity?

>This raises another question. What does "obsolete" mean?  RFC 821 
>and RFC 2821 describe

It means that there is a newer version of the specification (RFC).

>  the same standard. Upgrading implementations to comply with RFC 
> 2821 was not supposed to
>  break any connectivity. They describe the same protocol, so unless 
> you are interoperating with a peer that implemented some deprecated 
> features, you're good. OTOH,

In Section 3.3 of RFC 821:

  "The VRFY and EXPN commands are not included in the minimum
   implementation (Section 4.5.1), and are not required to work
   across relays when they are implemented."

In Section 3.5.2 of RFC 2821:

   "Server implementations SHOULD support both VRFY and EXPN."

In Section 3.5.2 of RFC 5321:

   "Server implementations SHOULD support both VRFY and EXPN."

If I know which specification is widespread, I can decide whether I 
should be able to rely on VRFY being available or not.  It is also 
unlikely that the VRFY is removed as the Standard is updated.  If the 
IETF decides to do that anyway, the specification is recycled at a 
lower maturity level.  In practice, it does not work like that for 
reasons I won't get into.

>It's true that under the current system RFCs never change. Even 
>advancing them to a higher level gives them a different number.

Actually no, the RFC only gets a different number if the text is changed.

>I don't think there's any incentive to do so.  RFC 4478 has been at 
>"Experimental" for 4 years, with at least 3 independent 
>implementations. But when I thought it was time to advance it to PS, 
>I was told (by an AD) "why bother?". It certainly didn't stop 
>implementers from implementing it.

If the specification has mind share, it will be implemented even if 
the RFC is Experimental.  If RFC 4478 fulfills the requirements for 
PS, it could be advanced unless it can be shown that it is 
technically unsound.  The PS could mean that someone bothered to look 
up the three independent implementations to see whether they are 
interoperable.  It might also help the author determine where the 
text is clearly understood.

>Also, it seems that in the last 4 years, the IETF has published only 
>3 full standards, 18 draft standards, and 740 proposed standards. I 
>think this tells us that there is very little incentive for 
>advancing a standard.

Or it might mean that the ADs are not interested in seeing the a 
specification advanced through the standards track.

If there isn't any motivation to advance a "standard", we might as 
well publish these RFCs as "Informational".

Regards,
-sm

---

From: Bill McQuillan <[email-masked]>
Date: Sun, 27 Jun 2010 12:17:46 -0700

It seems to me that this discussion is conflating two related but distinct
things: protocols and specifications.

The IETF is concerned with producing and refining *protocols*; however the
work products are specifications(RFCs).

A *protocol* such as SMTP is very mature and thus can be used by many
different parties to enable e-mail exchange with high confidence in its
interoperability. For example, SMTP has matured over the last several
decades by adopting DNS and MX routing, creating a mechanism for allowing
enhancements (EHLO), dropping unuseful features such as SEND and source
routing, separating Submission from forwarding (SUBMIT), among others.

The *specifications* for SMTP (RFC821, etc.) have been of varying quality
measured by their accuracy in describing the *protocol*. The goal of a
specification should be its capability for allowing someone to implement
the protocol accurately, not whether the protocol itself is well designed.

Therefore I would suggest that the SMTP protocol remains a Full Standard
even while successor specifications to RFC821, which are trying to describe
it, are cycling through levels of wordsmithing. Although the words
"Proposed" and "Draft" seem reasonable to describe these editing cycles I
am not sure that "Full" quite captures the goal of this process.

For what it's worth.

-- 
Bill McQuillan <[email-masked]>

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 28 Jun 2010 13:05:44 +0200

Hi SM,
the examples you give are /very/ significant, because of the miserable 
state of affairs that currently characterizes email.

On 27/Jun/10 19:32, SM wrote:
> Standard which has been obsoleted by RFC 5321 (Draft Standard). There
> are implementations out there that are STD 10 compliant. There are still
> a lot of implementations out there that are RFC 2821 compliant. I'll
> ignore the differences between these specifications. Most people mention
> RFC 2821 when it comes to SMTP. Do I implement RFC 2821 or RFC 5321?

People also implement any protocol variation they like.  The Internet 
is (still) driven by voluntary cooperation.  Developing a protocol 
requires a non-negligible effort, and the necessary insight can be 
acquired from the relevant RFCs.  However, deploying the protocol also 
involves installing and configuring the software.  The ratio between 
required insight and effort gets much higher for the latter phase, as 
does the number of people involved.

> Proposed Standard. It was updated by RFC 5672 in August 2009. Do I want
> to implement a specification that could be changed in two years or do I
> stick to the Draft or Internet Standard for maturity?

DKIM's policy is an even worse puzzle.  The impasse there is the 
requirement to avoid mandating recipients' behavior, while describing 
signing practices.  Of course, relying entirely on the English meaning 
of keywords whose effect is purposely unspecified, results in massive 
misunderstandings, and someone proposed to downgrade ADSP to 
experimental. (Would that affect ADSP implementers, though?)

IETF and ISOC are apparently unable to conceive an effective anti-spam 
protocol _and_ to lead implementers to accommodating cooperation. 
Possibly, a maturity level whose meaning is only related to savvy 
discussions among experts --when not to merely bureaucratic concerns-- 
is not very helpful, even indirectly, for the wider mass of protocol 
users who need to quickly gather the insight required to configure 
their machines steadily but up-to-dately.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 25 Jun 2010 17:56:40 -0400

The fact remains that RFC 821 has the STANDARD imprimatur and the better
specification that was intended to replace it does not.

It seems pretty basic to me that when you declare a document Obsolete it
should lose its STANDARD status. But under the current system that does not
happen.

This situation has gone on now for 15 years. Why would anyone bother to put
time an effort into progressing documents along the three step track when
most of the documents at the highest rank are actually obsolete?

What does STANDARD actually mean if the document it refers to is quite
likely obsolete?

On Fri, Jun 25, 2010 at 4:35 PM, Yoav Nir <[email-masked]> wrote:

> Why is this idiotic. RFC 821 needed to be obsoleted. It had some features
> that needed to be removed, and some things that may have been appropriate in
> 1982, but no longer so in 2001. "Proposed", "Draft" and "Full" refer to the
> maturity of a standard, not to how well it fits the current Internet. One
> could argue that 821 was very mature, because it needed a revision only
> after 19 years.
>
> Just because the old standard needs replacing, does not automatically mean
> that the new standard is just as mature as the old one.
>
> It does, however mean that the distinction is meaningless to implementers.
> In 2001 or 2002 we would expect someone implementing SMTP to implement 2821,
> a proposed standard, rather than 821, a full standard. While implementing a
> full standard gives you more assurance about the quality of the spec, it
> doesn't mean that "they" are not going to obsolete it ever.
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 28 Jun 2010 17:36:12 +0100

Scott Lawrence wrote:
> process.

I think this is far too late. Come what may, RFC 1149 (just to take one
deliberately extreme example) is forever going to be RFC 1149, it's too
late to rename it now. Separating the categories while still using RFC
with legacy examples is just not possible. Telling people "you can't
still call it an RFC" is not going to work.

> Only standards track documents should get an RFC number, and 

There are a lot of important RFCs that aren't standards track, often
more
important than some on the standards track. For example (not the best,
just
one I happen to have to hand) RFC 2309 is the only IETF document I'm
aware
of that describes RED, but it is Informational, not Standards Track.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Martin Rex <[email-masked]>
Date: Mon, 28 Jun 2010 21:35:00 +0200 (MEST)

> What does STANDARD actually mean if the document it refers to is quite

To me it looks like "Obsolete: XXXX" has been used with quite different
meanings across RFCs, and some current uses might be inappropriate.

Although it's been more than two decades that I read rfc821 (and
none of the successors), I assume that all those RFC describe _the_same_
protocol (SMTP) and not backwards-incompatible revisions of a protocol
family (SMTPv1,v2,v3).  I also would assume that you could implement an
MTA with rfc2821 alone (i.e. without ever reading rfc821), that is still
fully interoperable with an implementation of rfc821.  So for a large
part we are looking at a revised specification of the same single protocol,
and the term "obsoletes" should indicate that you can create an
implementation of the protocol based solely on a newer version of the
specification describing it and remain fully interoperable with an
implementation of the old spec when (at least when using the mandatory
to implement plus non-controversial recommended protocol features).

For RFCs that create backwards-incompatible protocol revisions, and
in particular when you still need the old specification to implement
the older protocol revision, there is *NO* obsoletion of the old
protocol by publication of the new protocol.  Examples where this
was done correctly:  IPv4&IPv6, LDAPv2&LDAPv3, HTTPv1.0&HTTPv1.1.

A sensible approach to obsolete a previous protocol version is to
reclassify it as historic when the actual usage in the real world
drops to insignificant levels and describe&publish that move in an
informational RFC (I assume that is the intent of rfc-3494).

Examples of clearly inappropriate "Obsoletes: XXXX" are the
TLS protocol revisions (v1.1:rfc-4346 and v1.2:rfc-5246) which describe
backward-incompatible protocol revisions of TLS and where the new RFCs
specify only the behaviour of the new protocol version and even
fail to clearly identify the backwards-incompatible changes.

And if you look at the actual use of TLS protocol versions in the
wild, the vast majority is using TLSv1.0, there is a limited use
of TLSv1.1 and very close to no support for TLSv1.2.

(examples https://www.ssllabs.com/ssldb/index.html
 http://www.ietf.org/mail-archive/web/tls/current/msg06432.html

What irritates me slightly is that I see this announcement
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=935&k2=34176&tid=1277751536

which is more of a bashing of existing and widely used versions
of SSLv3 and TLS, instead of an effort to improve _one_ of the
existing TLS protocol revisions and to advance it on the standards
maturity level and make it more easily acceptable to the marketplace.

Adding explicit indicators for backwards-incompatible protocol changes
in rfc-5246 might considerably facilitate the assessment just how much
changes are necessary to an implementation of a predecessor version
of TLSv1.2.  Btw. 7.4.1.4.1 Signature Algorithms extension appears
to be a big mess and fixing it wouldn't hurt.

MUST requirements in spec ought to be strictly limited to features
that are absolutely necessary for interoperability _and_ for the
existing market, not just nice to have at some time in the future.
The only TLS extension that deserves a MUST is described
in rfc-5746 (TLS extension RI).

One of the reasons why some working groups recycling protocol
revisions on proposed rather advancing a widely deployed protocol
to draft is the "the better is the enemy of the good".

-Martin

---

From: [email-masked]
Date: Mon, 28 Jun 2010 14:36:39 -0700 (PDT)

> > What does STANDARD actually mean if the document it refers to is quite

Simple: It means we're letting technical correctness get in the way of clarity.

> family (SMTPv1,v2,v3).

That assumption is incorrect. The diffrences are minor, but there are
differences - a couple of things, like EHLO instead of HELO or periods in
unquoted phrases, are allowed now, whereas lots of stuff that used to be
allowed has been removed.

The protocols don't even hahve the same names in common usage. The term "ESMTP"
is often used to refer to the SMTP variant described in RFC 5321 (RFC 2821 is
obsolete, BTW) that uses EHLO, and "SMTP" refers to the original RFC821 protocol.

> I also would assume that you could implement an
> fully interoperable with an implementation of rfc821.

Fully interoperable? Not even close. A lot of stuff has been removed from RFC
5311. If someone attempts to use those RFC 821 features, things aren't going to
interoperate.

Now, the consensus is that those features are useless, dangerous, rarely if
ever implemented, or sometimes all three, and we're are better off for their
absence, but that doesn't make your assertion valid.

> So for a large

It is a revised specification and the *service* it provides remains the same.
But the protocol has changed. Some things have been removed; other things have
been added. There's fallback where it is necessary, but there are also cases
where functionality has simply been removed.

> to implement plus non-controversial recommended protocol features).

That would be an absolutely absurd requirement to impose. Full interoperability
is far too high a bar.

> was done correctly:  IPv4&IPv6, LDAPv2&LDAPv3, HTTPv1.0&HTTPv1.1.

THat's also absurd and overly constaining. These choices aren't amenable to
being codified as a fixed set of rules. Context has to be considered.

> informational RFC (I assume that is the intent of rfc-3494).

This approach may indeed be appropriate in some cases. There are bound
to be cases where it is inappropriate, though.

>  http://www.ietf.org/mail-archive/web/tls/current/msg06432.html

Whereas, in the case of email, the vast majority of MTAs now support ESMTP and
the *overwhelming* majority of MUAs support MIME.

> to be a big mess and fixing it wouldn't hurt.

Well, I cannot speak to the issues surrounding TLS, but insofar as email goes,
the lesson we finally learned is that you have to design for deployment. Like
it or not, we don't operate in a "field of dreams". The reality here is "if you
buuld it, nobody is going to give a shit without some damn good reasons".

There were at least four attempts to upgrade message formats prior to MIME.
THey all failed because every single one of them failed to give adequate
consieration to deployment issues.

> in rfc-5746 (TLS extension RI).

Once again this is overly constraining. There are many MUSTs in email standards
that are present to prevent operational issues from arising. Or to address
potential security issues. And these often have nothing to do with
interoperability - in fact I can think of several where interoperability was
intentionaly traded off in order to get better operational characteristics or
security.

> to draft is the "the better is the enemy of the good".

Another problem which for some reason hasn't plagued the base email
specifications, the majority of which are at draft.

				Ned

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Jun 2010 17:01:21 -0700

> to draft is the "the better is the enemy of the good".

"Make everything as simple as possible, but not simpler." Albert Einstein

The current scheme is already too simple.  Too simple because any 
resulting utility does not justify promotion efforts.  Reducing the the 
status categories will not greatly impact the goal of spending less time 
at advancing related RFCs to the same level, where often an originating 
wg will have closed.  Making changes that impact a large number of 
interrelated protocols will have these efforts causing as much 
disruption as utility.  Rather than providing stability, efforts at 
"simplification" are likely to inject as many errors, as those corrected.

Four years ago, an effort to create a "cover sheet" for "standard" 
protocols was attempted.  After gaining majority support within the wg, 
subsequently the wg closed without a clear explanation for the IESG 
push-back.  Often no single RFC or STD encapsulates a "standard".  In 
addition, references to a wider set depends upon an evolving set of 
numbered RFCs, where tracking these relationships often requires complex 
graphs.

With a "cover sheet" approach, "core" elements are described separately 
from "extension",  "guidance", "replaces", "experimental", and 
"companion" elements.  Many overlapping protocols can be defined as 
representing different associations of RFCs.  This scheme lessens 
dependence on a concise relationship described in each RFC,  or 
attempting to resolve relationships based upon the roughly maintained 
categories that frequently offer little insight or reflect actual use.

Cover sheets that groups related documents allow easy reference to 
amendments per separate, but related protocols.  The reason the current 
system is broken is related to its inability to construct a protocol 
from existing RFCs, where amendments can be scoped to different 
overlaying protocols.  The cover sheet is more user friendly, by giving 
protocols consistent names, rather than ever changing number sets.

http://tools.ietf.org/html/draft-otis-newtrk-rfc-set-02
http://www.sonic.net/~dougotis/newtrk/

Sorry, but this site was constructed 4 years ago, and some links need to 
be updated.

-Doug

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 29 Jun 2010 11:08:17 +0200

> should lose its STANDARD status. But under the current system that does not

We could write a draft to move RFC 821 to Historic, though.  Then it
would lose its full standard status.  Are there any reasons not to do
that?

I don't think we want implementers to read RFC 821 except for historical
purposes, and instead want them to read RFC 5321.  Moving RFC 821 to
Historic would convey that message, I believe.

/Simon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 28 Jun 2010 18:00:13 -0400

The reason I chose RFC2821 is that there is really no basis on which the
earlier document is better.

RFC821 was accepted when the process was far less stringent. The working
group that produced 2821 was chartered to improve the documentation of SMTP
rather than redesign the protocol.

What people are asking for is that the transition from one standards state
to another to actually mean something. If we think of the world as a huge
collection of loosely coupled, probabilistic communicating finite state
machines (similar to CSP but without rendezvous), I cannot think of any
system in that world that would undergo a state transition on receiving the
message RFC2821 has gone from DRAFT to STANDARD. Nor can I think of any
system where the probability of a state transition would be affected by
whether RFC2821 was in the one state or the other.

What I and others conclude from this fact is that the current system as
documented is broken. There is no point in fixing the practice to match the
theory because the theory has been rejected FOR GOOD REASON.

The current missmatch between theory and practice is hurting the IETF. I
have been involved in the decision of where to take quite a few standards
proposals now. And it must be said that the fact that nothing now becomes an
IETF standard until the fact is irrelevant causes resistance.

---

From: Nathaniel Borenstein <[email-masked]>
Date: Wed, 30 Jun 2010 07:38:00 -0400

If the problem we are trying to solve is how developers decide which RFC to implement in this situation, perhaps all we need to do is make sure that the status conveys all the relevant information.   The rfc-index file currently lists 821 as

(Obsoletes RFC0788) (Obsoleted by RFC2821) (Also STD0010) (Status: STANDARD)

while 5321 is listed as

(Obsoletes RFC2821) (Updates RFC1123) (Status:  DRAFT STANDARD)

All the information is there, but you have to work to track it down.  821 is listed as obsoleted by 2821, which is listed as obsoleted by 5321.  It's understandable if people miss the point, but the info is all there, so it's an information presentation issue.  We just need to make it clearer.  

A simple way to do that would be to say that anything with a STANDARD or DRAFT STANDARD status should have that status clearly modified by any "Obsoleted" clause, which should point straight to the most current version.  Thus, for 821, we might have:

(Obsoletes RFC0788) ( (Also STD0010) (Status: STANDARD -- Obsoleted by RFC5321)

I think most developers would have a hard time ignoring that phrasing, and it doesn't require any formal action to change the status of the older draft.  -- Nathaniel