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

Joe Touch <touch@ISI.EDU> Thu, 02 October 2008 17:20 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4E13A69DA; Thu, 2 Oct 2008 10:20:07 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8AEB3A6816 for <tcpm@core3.amsl.com>; Thu, 2 Oct 2008 10:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubbCjqZIRDdw for <tcpm@core3.amsl.com>; Thu, 2 Oct 2008 10:20:00 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 32FA73A67E4 for <tcpm@ietf.org>; Thu, 2 Oct 2008 10:20:00 -0700 (PDT)
Received: from [75.215.151.23] (23.sub-75-215-151.myvzw.com [75.215.151.23]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m92HJTft024228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 10:19:32 -0700 (PDT)
Message-ID: <48E502A1.5060006@isi.edu>
Date: Thu, 02 Oct 2008 10:19:29 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Lars Eggert <lars.eggert@nokia.com>
References: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> <13D1EAB852BE194C94773A947138483D061CA91D@xmb-sjc-21c.amer.cisco.com> <20081002001625.GQ60793@zod.isi.edu> <0A1AC67E-26EE-4553-92FA-7FDC46685B37@nokia.com>
In-Reply-To: <0A1AC67E-26EE-4553-92FA-7FDC46685B37@nokia.com>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= <ah@tr-sys.de>, tcpm@ietf.org, David Borman <david.borman@windriver.com>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, ext Ted Faber <faber@ISI.EDU>, Randy Stewart <randall@lakerest.net>, "Mitesh Dalal \(mdalal\)" <mdalal@cisco.com>, "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" <Wesley.M.Eddy@nasa.gov>
Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

-----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