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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]