Subject: Re: [tsvwg] When to use Updates -- was: SCTP NAT support, ...

From: Alfred Hönes <[email-masked]>
Date: Wed, 27 Jan 2010 01:28:08 +0100 (MEZ)

James,
thanks for your response.

At 02:36 PM 1/26/2010, James M. Polk wrote:

>> At 01:52 PM 1/26/2010, Alfred Hönes wrote:
>> ...
>>
>> "Instructions to Request for Comments (RFC) Authors", the
>> "successor of RFC 2223",
>>   <http://www.rfc-editor.org/rfc-editor/instructions2authors.txt>
>> states in Section 2.11:
>>
>> |   Updates
>> |
>> |      Specifies an earlier document whose contents are modified or
>> |      augmented by the new document.  The new document cannot be
>> |      used alone, it can only be used in conjunction with the
>> |      earlier document.
>>
>> That's the current definition, yet apparently not always enforced
>> by the RFC Editor, in order to avoid conflict with the RFC stream
>> "gatekeepers".   :-)
>>
>> IMO, "cannot be used alone, can only be used in conjunction with
>> the earlier document" is a prudently chosen clause specifying a
>> criterion that can be decided upon in a rather objective manner.
>
> ...
>
> put another way, this is discussing the differences between a new
> doc being dependent or independent of the "older" (or base) doc.

Agreed.  That's what the above definition takes care of.

> Unfortunately -- this doesn't make the case in either way to me
> because any extension to a base protocol is therefore an update
> to that protocol because the extension is pointless without the
> base protocol.

I do not understand you here in the first line of that sentence.
The subsequent 3 lines are an essential corollary of the above
definition.
Since there's no alternative "Amends RFC xxxx" relation available,
according to this definition, all such dependencies are tagged as
"Updates ...".

Can you "use" a protocol extension (i.e. implement/deploy/manage
it, or "make use of it as a user") without doing the same with the
base protocol?
Or likewise, an extension of an extension without the first one?

No.  Hence it follows from this definition, in your words:
  "Any extension to a base protocol is therefore an update to that
   protocol because the extension is pointless without the base
   protocol."

> I can easily see one extension to a protocol being independent
> from another extension to the same protocol, but neither
> extension can work at all without the original protocol
> specification.

Yes.
The strict application of the above definition would weave a web
of (asymmetrical) metadata relations representing a directed graph
of semantical and implementation dependencies for a protocol and
all of its extensions that can be navigated by readers (or "users")
following the "Updated by" arrows to locate _all_ documents of
potential interest related to a given (more basic) document.

(Since these relations are going to be entered in the RFC index
with "inbound" and "outbound" arrow labels (i.e. "UPDATED BY"
and "UPDATES" clauses in the RFC index), they can be navigated
easily bidirectionally, unlike References.  That's an important
added-value feature.)

Due to the asymmetrical (unidirectional) nature of the relation,
there's no harm in tagging independent extensions of the same
protocol with the same "Updates ..." property; doing so does not
cause an inadvertant "Updates" relation between these extensions.

That's how I understand the intent of above definition.

For instance, there are extension documents for IMAP that do not
even contain "IMAP" (in the abbreviated or the expanded form) in
their title, and at least one doesn't even do so in the Abstract.
Would the above definition have been applied, it would be much
easier to locate all IMAP related RFCs, e.g. for an implementer
who, in a first step, has to sreen the existing specs in order to
define the technical scope and range of support in his product.

Similarly, the lack of such complete semantical web was one of the
reasons why RFC 4614 (TCP Documentation Roadmap) had to be written
(and arguably should be maintained actively).

As a recent counterexample for applicability of the relation,
the recent RFC 5661 is independent of previous specifications of
NFS although it defines an "updated" version ("Minor version 1")
of the NFSv4 protocol specified in RFC 3530 and its predecessors;
in fact, RFC 5661 encourages support of older protocol versions
in parallel to accommodate various deployments and boundary
conditions.
Hence, also under the above definition it would be inappropriate
to declare "RFC 5661 Updates RFC 3530".  Obviously, there are
scenarios where logical strength counters intuitive application
of the plain, colloquial term "updates".

Marginal note, from a mathematical point of view: This observation
is rooted in the fact that the above definition yields a strictly
transitive binary relation "Updates", whereas the colloquial
"updates" obviously is not transitive.  And note that "Obsoletes"
is conceptually transitive as well.  For both relations, only the
minimal "generating" elements are entered into the database; the
complete relation is the "transitive hull" of these entries.

This is what the introductory text of the RFC index files describes
for the relations "Obsoletes", "Obsoleted by", "Updates", and
"Updated by", without any distinction:
  "Generally, only immediately succeeding and/or preceding RFCs are
   indicated, not the entire history of each related earlier or
   later RFC in a related series."
It seems reasonable to assume that the original RFC Editor had
transitive relations in mind when he wrote this sentence.

This could be taken as an argument to actually and seriously adopt
the above definition for "updates" because it consistently indeed
induces a transitive relation -- unlike the currently observed
usage of "Updates" in the sense of "Changes" or "Modifies" (both
obviously non-transitive relations).
Reportedly however, there were social and contractual reasons why,
in the age of early RFCs, specifications have never been "changed"
or "modified" -- that would have been politically incorrect --
and why "Updates" then has been used sometimes synomymously for
these terms.

To sum up these results:

The RFC Index -- since at least 2 decades -- defines "Updates" and
"Obsoletes" as transitive relations.  If we try to superimpose
semantics to these relations that are not compatible with that
property, we will get problems.
The IETF did so, and that's why we now are having trouble with
the definition and application of the "Updates" relation.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+