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