Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FWIW, we're dealing not only with what RFC2223 says in this regard, but
the current IETF culture of when to use "updates".

As I've noted, there are other extensions to TCP that are more "updates"
than this. We have a roadmap document to more clearly explain the
relationship of components to 793; when that document is updated,
tcpsecure should be added to that. Given the complexity of that
document, this label isn't going to help, and IMO will misdirect
implementers to include this where it wasn't necessary.

I see no reason to lead the charge of changing IETF culture on this
issue with this document, and specific reasons NOT to use this document
as the defining case.

Joe

Lars Eggert wrote:
> Hi,
> 
> FYI, Pasi Eronen pointed me at RFC2223, which defines what "updates"
> means. In Section 12, it says:
> 
>    12.  Relation to other RFCs
> 
>    Sometimes an RFC adds information on a topic discussed in a previous
>    RFC or completely replaces an earlier RFC.  There are two terms used
>    for these cases respectively, Updates and Obsoletes.  A document that
>    obsoletes an earlier document can stand on its own.  A document that
>    merely updates an earlier document cannot stand on its own; it is
>    something that must be added to or inserted into the previously
>    existing document, and has limited usefulness independently.  The
>    terms Supercedes and Replaces are no longer used.
> 
>    Updates
> 
>       To be used as a reference from a new item that cannot be used
>       alone (i.e., one that supplements a previous document), to refer
>       to the previous document.  The newer publication is a part that
>       will supplement or be added on to the existing document; e.g., an
>       addendum, or separate, extra information that is to be added to
>       the original document.
> 
> Nothing in that text talks about conditional applicability, and the
> argument that tcpsecure is an addendum to be added as an optional
> component to RFC793 can be made.
> 
> The unfortunate thing is that the IETF's running code has been different
> from what RFC2223 describes, at least to some degree even back then and
> certainly since. I other words, according to the definition in RFC2223,
> many more RFCs should have been updating RFC793 over the years, not to
> speak of other RFC/protocol families.
> 
> Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjlAqAACgkQE5f5cImnZrsr7ACg+qDI6l+4QfjyI2UYCsxs6o4T
tzEAoNXu6K7Pz2/7uXhyiqKwH+qIksRk
=KhuK
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm