[tcpm] exegesis of 'Updates' -- was: ... review of draft-ietf-tcpm-tcpsecure[-10]

[Alfred Hönes <[e-mail]>]

Folks,
I observe that this discussion (which my initial posting has
triggered involuntarily) is getting ridiculous.

Let's return from fine-grained nano-arguments to the roots.

We are discussing the simple "relations" in the metadata of RFCs.

These serve the purpose to visibly link these documents together
in a coarse, qualified manner, and thus enable any reader not
aware of lengthy WG discussion list threads to find a web of
pointers which should assist her/him in finding the related
documents, when starting with a 'well known' base document.

Admittedly, the 'vocabulary' available is very simple, but one
of the main issue I had when I once started reading RFCs was the
very scarce and poor usage of this simple vocabulary, "Updates",
"Obsoletes", and "Also".
My perception frequently was that there were far too many MUSTs
and SHOULDs and MAYs inside the documents, and far too few
"Udates" helping the reader navigate the RFCs, in the metadata.
(It's similar to web pages with no hyperlinks on 'home pages'
[or equivalent] pointing to them!)

Any implementor or analyst reading RFC 793 should be made aware
of the tcpsecure RFC, as soon as it is out (and I really hope to
see it soon in the RFC index!), because that document contains
qualified statements this working group has judged.
[... in an incommensurate long period of discussion holding off
this long-expected document -- personal note.]
He/she should be pointed to this document by the RFC metadata,
and should read it (the latter seems to be the consensus of
the WG, isn't it?) -- otherwise publishing the document would
be rather moot.

The "Updated by" metadata links do not imply requirements
language in any way, they point the reader to documents that
(hopefully) contain an applicability statement and their own,
and detailed requirements language.

If a new document adds, e.g., new options, to properly designed
extensibility hooks of a protocol, without affecting/changing
processing rules of the protocol, that memo does not "Update"
the base document for that protocol, and that document can be
easily picked up by tracing the IANA Registry for the namespace
forming the extensibility hook.  But if a document discusses
new requirements for a protocol that have come up in the real
world, and it contains 'considerations' about modifications
to the processing rules laid down in another document (which
in this particular case already have been adopted by most
significant players in the marketplace as inevitable and
indispensible changes for security reasons), this new document
SHOULD be tagged in the RFC metadata as "Updates <the old one>".

Don't forget:
This WG is chartered for the *MAINTENANCE* of TCP.
If you don't want to make that maintenace visible, you are in
danger to dismiss your mission (and the mission of the IETF and
its Standards Process).  Since RFCs are immutable, RFC Errata
and additions to the RFC metadata are the only ways to make
an act of maintenance for a document visible at first place.

I only see one other option (but I guess that's not a real option
in practice, due to workload): *regularly* update RFC 4614 .
Such documents (and there are far too few of this kind!)
provide enough space to discuss the nuances of conditional
MUSTs and SHOULDs in case of applicability etc. etc. at length,
if deemed necessary.

Therefore my recommendation:

+++   Be very careful with "Obsoletes", but be generous
+++   with "Updates", for the benefit of RFC readers !

Kind regards,
  Alfred.


P.S.:
The discussion has mentioned the tiny number of "Updated by"
for RFC 793, one of the oldest and most important standards
of the IETF.  Many technicians not aware of the discussions
in this WG would take this as a severe indication, or even
evidence for lack of maintenance for TCP!

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+



_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm