RE: Consensus Call for draft-housley-tls-authz

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

Title: Re: Consensus Call for draft-housley-tls-authz

When British Leyland shut down the assembly line for the Triumph TR7 they found a note that said, 'Your proposal to prime and paint the TR7 bodyshells before moving them a hundred miles in open rail cars to the assembly plant has been made before. If only stopping rust was so simple'.

 

The fact that a proposal has been made before and ignored does not diminish its value.

 

How frequently does a sensible proposal have to be made to receive a susbstantive response?

 

 

---

From: ietf-bounces@xxxxxxxx on behalf of Steven M. Bellovin
Sent: Mon 3/9/2009 6:40 PM
To: Stephan Wenger
Cc: SM; rms@xxxxxxx; ietf@xxxxxxxx
Subject: Re: Consensus Call for draft-housley-tls-authz

On Mon, 09 Mar 2009 15:35:31 -0700
Stephan Wenger <stewe@xxxxxxxxx> wrote:

> The IETF might view it this way.  Large parts of the
> (standardization) world does not.  One example in my field of work is
> FLUTE, and the surrounding infrastructure of frameworks and FEC
> codes.  To the best of my recollection, these specifications were
> originally issued as Experimental RFCs, for reasons of congestion
> control worries.  (They are also heavily encumbered, but that was not
> really an issue according to my recollection.)  The Experimental
> status did not stop 3GPP and other SDOs to normatively reference
> them, and treat them just like any other IETF RFC.  Note that 3GPP
> could NOT do that with a journal publication...  I could name more
> examples, both when it comes to referencing SDOs and referenced RFC
> types (including normative references to at least Historic, Obsolete,
> Informational).

This is, I think, the second- or third-most-common topic on the IETF
list: should we rename the document series to prevent that...  (#1 is
non-ASCII formats for RFCs; #2 -- by volume of postings, rather than
frequency of discussion -- might be IPR.)

Other than giving up the RFC label for Experimental documents, it's
hard to see what the IETF can do.

                --Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf