Re: motivations (was: Re: draft-housley-two-maturity-levels-00)

On 6/28/10 12:35 PM, Martin Rex wrote:
> 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".
>    
"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





_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf