Subject: Alternative Proposal for Two-Stage IETF Standardization

From: Dave CROCKER <[email-masked]>
Date: Tue, 09 Nov 2010 23:24:29 +0800

Folks,

A few of us have formulated an alternative proposal for streamlining the IETF 
standards process.  We hope that it at least adds to the mix of discussion in 
the community.

d/

-------- Original Message --------
Subject: I-D Action:draft-crocker-ietf-twostage-00.txt
Date: Tue, 09 Nov 2010 07:15:02 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

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

	Title           : Two-Stage IETF Standardization
	Author(s)       : S. Dawkins, et al.
	Filename        : draft-crocker-ietf-twostage-00.txt
	Pages           : 8
	Date            : 2010-11-09

RFC 2026 specifies a three-stage Standards Track.  As currently
practiced, IETF standards track documents typically attain only the
first stage.  This proposal discusses the problems caused by the
disparity between documented procedures and actual practice, and
proposes a simplified, two-step standard track, which will streamline
the IETF standardization process, with distinct benefits for each
stage.  Clarification of the criteria for handling documents re-
submitted as Proposed Standard is also provided.

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Nov 2010 10:24:14 +1100

> standards process.  We hope that it at least adds to the mix of discussion in 

Dave, can you please fix/change/report to the vendor that your MUA as it is
not producing valid mime.  My MUA reported this as being broken.

	Content-Type: Message/External-body;
	 name="draft-crocker-ietf-twostage-00.txt"
	Content-Transfer-Encoding: 7bit
	Content-Disposition: attachment;
	 filename="draft-crocker-ietf-twostage-00.txt"

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Nov 2010 12:59:16 +1300

Hi,

I could live with this. I could live with draft-housley-two-maturity-levels.
I could also live with draft-dawkins-pstmt-twostage (2003), or
draft-atkinson-newtrk-twostep (2006), or even draft-carpenter-newtrk-twostep (2005).

For that matter I could live with draft-loughney-newtrk-one-size-fits-all (2006).
We do, after all having running code proof that a single stage standards
process works just fine. (In case that isn't obvious, the running code
is called 'the Internet' and the single stage is called 'proposed standard'.)

Just one tiny nit in draft-crocker-ietf-twostage-00. 'IS' is the abbreviation
for International Standard, as in IS8473. It's worth steering clear of
that confusion. Beyond that, I just don't care which variant we choose.

Regards
   Brian Carpenter

On 2010-11-10 04:24, Dave CROCKER wrote:
> Folks,
> 
> A few of us have formulated an alternative proposal for streamlining the
> IETF standards process.  We hope that it at least adds to the mix of
> discussion in the community.
> 
> d/
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 10 Nov 2010 13:06:06 +0800

All I did was a forward of what was sent over ietf-announce.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Russ Housley" <[email-masked]>
Date: Wed, 10 Nov 2010 22:14:58 -0500 (EST)

Dave:

The document says:

      (Full) Internet Standard:   The Internet community achieves rough
         consensus -- on using the running code of a specification.

This causes me pause, because it does not say that the RFC was sufficient
to produce interoperable implementations.

Perhaps this is a problem with the words that were selected, but it might
be a fundamental concern.  I can't tell from the draft.  Please explain.

Russ

> IETF

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 11 Nov 2010 12:25:10 +0800

> be a fundamental concern.  I can't tell from the draft.  Please explain.

Russ,

Your diagnostic assessment is exactly right:  The precise wording needs to be 
better.

I -- since I'm the editor of the doc, I get wording blame -- took it as a given 
that "widespread use" required interoperability.  And I wish I could say that 
you were the first to notice the potential hole is our existing language.  (In 
fact, it took some iterations before I comprehended what problem was being seen 
in the language.)

Frankly, I think it's an edge condition, because the 'violation' would be having 
an IETF standards track specification that gained widespread use, but with only 
one implementation.

Or, at least, that's the hole in the language that has been noted to me.  If you 
see other problems, please explain.

To establish the base:  It is not possible to achieve widespread use on the 
Internet without having multiple components interacting.  That's called 
interoperability.

However, the interoperability might be among components that are clones of a 
single code base.

So our language needs to be enhanced to cover multiple implementations.  And as 
long as the language hood is up, we might as well put in a turbo-booster that 
asserts the higher octane 'interoperability' word.

Does that cover your concern?

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 11 Nov 2010 14:47:40 +0800

Folks,

> asserts the higher octane 'interoperability' word.

A hallway conversation with Russ added an item that simply had not occurred to me:

    There might be multiple implementations that rely on on undocumented 
modifications of the spec.  This means that an additional, interoperable 
implementation cannot be made purely from the specification.

Again, I believe the requirement for the document is "merely" to get the wording 
right.  I do not believe any of us differ on the actual meaning we are trying to 
achieve.  That is, I have not seen anything that indicates we have disparity 
about the intended requirement.

Test language: (*)

      (Full) Internet Standard:

      The Internet community achieves rough consensus -- on using
      the multiple, independent implementations of a specification

and

      3.3.  [Full] Internet Standard (IS)

      This is the existing final standards status, based on attainment of
      significant community acceptance, as demonstrated by use of multiple,
      independent implementations that conform to the specification.

d/

ps.  I just realized that the original language that Russ cited said "on using 
the running code of a specification".  "Of a specification" explicitly means 
that the stuff that is running is the spec and, therefore, can't really mean 
that it's using hallway agreements.  (However I think it's dandy to make the 
Section 3.3 language bullet-proofed against creative misunderstanding.)

(*) This is just from me; it hasn't been vetted with my co-authors.

-- 

   Dave Crocker

---

From: "Russ Housley" <[email-masked]>
Date: Thu, 11 Nov 2010 03:23:59 -0500 (EST)

Dave:

This is a significant improvement from my perspective.  We need a
mechanism to implement it.  The mechanism does not need to be heavy
weight, and it might be as simple as some statements in a Last Call,
allowing the community to support or challenge them.

Russ

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Nov 2010 16:27:31 +0800

> (*) This is just from me; it hasn't been vetted with my co-authors.

+1 here.

Peter

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 11 Nov 2010 02:44:08 -0600

Russ,

> allowing the community to support or challenge them.

Thank you for the hallway conversation on this.

When I counted last week, only 80 implementation reports have been filed 
with the IESG in the history of "ever", so this doesn't seem like the right 
hurdle for advancement.

I think your suggestion to make assertions at Last Call time and asking for 
supporting/challenging statements sounds very reasonable. The IESG can do 
the right thing based on Last Call comments.

Thanks,

Spencer

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 11 Nov 2010 18:55:40 +0800

> allowing the community to support or challenge them.

If I understand both your statement here and your comment in the hallway 
discussion, I suspect that the requirement would be satisfied by having various 
folk submit a form with some standard language on it, making an attestation 
along the lines of the language I submitted.

Said more plainly:  Some people would need to claim that the developed or know 
of an independent implementation that conforms to the spec and works with other 
specs.

Forgetting about the task of agreeing on the exact language, would this suffice?

I guess the Last Call message would include something like:

     The following individuals and/or organization
     have stated that [...]:

Yes?

d/
-- 

   Dave Crocker

---

From: "Russ Housley" <[email-masked]>
Date: Thu, 11 Nov 2010 06:10:37 -0500 (EST)

>      The following individuals and/or organization

I think it would be sufficient to say something like: The following
implementations represent a significant Internet deployment and they are
based on the specification in RFC <n>:

  - <a>
  - <b>
  - <c>
  - ...

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 11 Nov 2010 19:23:06 +0800

On 11/11/2010 7:10 PM, Russ Housley wrote:
> based on the specification in RFC<n>:
>
>    -<a>
>    -<b>
>    -<c>
>    - ...

wfm.

d/
-- 

   Dave Crocker

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 11 Nov 2010 10:25:40 -0600

>> based on the specification in RFC<n>:

and seems very reasonable to me as well...

Spencer

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Nov 2010 19:17:25 +0100 (MET)

> implementation cannot be made purely from the specification.

IMHO this is the most important aspect about "document maturity":

That the document is sufficiently clear and the protocol useful
_exactly_ as specified, so that whenever two independent
implementations fail to interoperate that the one that must be
considered broken and requires fixing is with a high probability
the one that deviates from the specification, rather than
require changes to the spec and all compliant implementations.

There are a number of popular protocols that are heavily used,
but when it comes to interoperability, the devil is in the details
and the details are a huge mess.

TLS is an example of plenty "defective" implementations.

(e.g. protocol version numbers in various places, presence of TLS Hello
 extensions or (Hello) compression algorithms, (lack of) sending alerts,
 effect of warning level alerts on the handshake, requirement for
 certificate_authorities in CertificateRequest handshake message,
 requirement for in-order and _complete_ certificate chains, variable
 size padding, fragmentation of handshake messages, "server-gated crypto",
 sensitivity to certain certificate attributes, misappropriation
 of the ASN.1 type T61String, creation and distribution of commercial
 RootCA cert for TLS PKI that clearly violates rfc2459+rfc3280+rfc5280,
 to name a few)

The result of the mess is that most browsers these days have given
up entirely the concept of SSL/TLS interoperability and use a heuristic
of reconnect fallbacks _at_the_application_level_, i.e. try a protocol
feature, run into one of those interop problems, abort, and the
calling app is supposed to retry with a less optimistic set of
features.

And there are folks who believe that every TLS-enabled application
should have to implement reconnect fallback heuristics to cope
with the SSL/TLS interop mess of the installed base rather than
sticking with a conservative subset of TLS that _is_ fairly
interoperable (extension-less TLSv1.0 or even extension-less SSLv3).

-Martin

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 12 Nov 2010 07:09:51 +0800

On 11/12/2010 2:17 AM, Martin Rex wrote:
> of reconnect fallbacks_at_the_application_level_, i.e. try a protocol

Nothing the IETF does can prevent or fix this kind of implementation divergence.

The only way harmonization is achieved is by an active constituency of the 
industry pressing for it, primarily through interoperability testing that is 
limited to the specification.

The only role of the IETF in such a process is to aid in getting agreement on 
any specification changes that might be needed, when the divergence is due to 
/enhancements/ that are non-standard.

d/

-- 

   Dave Crocker

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Nov 2010 01:05:51 +0100 (MET)

Dave CROCKER wrote:
> 
> I -- since I'm the editor of the doc, I get wording blame -- took it as
> a given that "widespread use" required interoperability.  And I wish
> I could say that you were the first to notice the potential hole is our
> existing language.  (In fact, it took some iterations before I
> comprehended what problem was being seen in the language.)
> 
> Frankly, I think it's an edge condition, because the 'violation' would
> be having an IETF standards track specification that gained widespread
> use, but with only one implementation.

I've seen that happening several times.

One single vendor having created an installed base that is
simply to large to ignore (several millions to several hundred millions)
and with significant incompatibilities to the original spec.

http://tools.ietf.org/html/rfc4178#appendix-C

http://tools.ietf.org/html/rfc5929#section-8

-Martin

---

From: [email-masked]
Date: Thu, 11 Nov 2010 18:07:18 -0800 (PST)

> with the IESG in the history of "ever", so this doesn't seem like the right

I assume that figure was arrived at by looking at:

  http://www.ietf.org/iesg/implementation-report.html

If so, it's apropos of nothing, since the list is incomplete. Just as one
example, MIME interop info isn't on it, and that information definitely was
generated.

> the right thing based on Last Call comments.

For the record, I am entirely in favor of Russ' proposal but entirely opposed
to this new proposal, because it eliminates the parts of the process that are
working (proposed -> draft criteria) and retains the ones that aren't (draft ->
full).

In fact given a choice between this new proposal and the current process, I
prefer the current process.

				Ned

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 11 Nov 2010 20:24:24 -0600

Hi, Ned,

> example, MIME interop info isn't on it, and that information definitely 

Yes, that's correct. That's where the figure came from.

Spencer

---

From: Eric Burger <[email-masked]>
Date: Fri, 12 Nov 2010 11:14:14 +0800

And for the most part, we have had decent success with self certification in SIP and VPIM, as two examples.