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

Lars Eggert <> Thu, 02 October 2008 16:57 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 1047E3A6A0C; Thu, 2 Oct 2008 09:57:39 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D8CA3A6A0C for <>; Thu, 2 Oct 2008 09:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BwcAilfK-fy9 for <>; Thu, 2 Oct 2008 09:57:34 -0700 (PDT)
Received: from (unknown [IPv6:2001:2060:40:1::123]) by (Postfix) with ESMTP id 2F4463A694C for <>; Thu, 2 Oct 2008 09:57:34 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id m92Gtn6j012374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Oct 2008 19:55:50 +0300 (EEST) (envelope-from
Message-Id: <>
From: Lars Eggert <>
To: ext Ted Faber <faber@ISI.EDU>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 02 Oct 2008 19:55:49 +0300
References: <> <> <>
X-Mailer: Apple Mail (2.929.2)
X-Virus-Scanned: ClamAV 0.94/8371/Thu Oct 2 13:15:33 2008 on
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Thu, 02 Oct 2008 19:55:59 +0300 (EEST)
Cc: Alfred HÎnes <>,, David Borman <>, Joe Touch <touch@ISI.EDU>, "Anantha Ramaiah (ananth)" <>, Randy Stewart <>, "Mitesh Dalal (mdalal)" <>, "Eddy, Wesley M. (GRC-RCN0)[VZ]" <>
Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0081354451=="


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


       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.

tcpm mailing list