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

"Eddy, Wesley M. (GRC-RCN0)[VZ]" <> Tue, 30 September 2008 17:57 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id E554F3A6BBE; Tue, 30 Sep 2008 10:57:41 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4704F3A6BD8 for <>; Tue, 30 Sep 2008 10:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.25
X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xJJDxpz03yGI for <>; Tue, 30 Sep 2008 10:57:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4607B3A6BBE for <>; Tue, 30 Sep 2008 10:57:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4CDCDA8143; Tue, 30 Sep 2008 12:57:56 -0500 (CDT)
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id m8UHw1J8017125; Tue, 30 Sep 2008 12:58:01 -0500
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Sep 2008 12:58:00 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 30 Sep 2008 12:58:00 -0500
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
Thread-Index: AckjFO+lNnhV8IygRWO9tjxdRj/8mQAASsbwAAIBL4AAANa5QAAA1Gww
References: <> <><><><><> <> <> <>
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <>
To: "Anantha Ramaiah (ananth)" <>, David Borman <>, Lars Eggert <>,
X-OriginalArrivalTime: 30 Sep 2008 17:58:00.0579 (UTC) FILETIME=[13DD9D30:01C92326]
Cc: Alfred HÎnes <>, "Mitesh Dalal (mdalal)" <>,, ext Joe Touch <>
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>-----Original Message-----
>From: Anantha Ramaiah (ananth) [] 
>Sent: Tuesday, September 30, 2008 1:47 PM
>To: Eddy, Wesley M. (GRC-RCN0)[VZ]; David Borman; Lars Eggert; 
>Cc: Alfred HÎnes; Mitesh Dalal (mdalal);; 
>ext Joe Touch
>Subject: RE: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
>> My personal opinion on the number of angels on the head of this
>> pin is that 3168 redefines bits that were formerly reserved.  Thus
>> it "updates" the description of those bits in 793 (they're no longer
>> reserved).  *Regardless* of the fact that 3168 is itself optional,
>> those bits are no longer available in the way 793 describes.  *That*
>> is why it has to "update" even though it's optional itself.
>> The tcpsecure document does not "update" in that sense, as it only
>> contains optional alternative state machine arcs; the arcs defined
>> in 793 are still able to be used in the way 793 describes ... they
>> aren't "updated", but there's now an alternative to them.
>Are you saying that we should construe that "alternate 
>processing" doesn't update the RFC?. Now, the update itself 
>can be optional. In other words, my point is that the current 
>meaning and usage of "updates" is to be used for any updates 
>to the RFC, irrespective of the fact it is minor, major or 
>optional. Agreed that, currently there is fine granularity in 
>describing an update i.e, "minor update, medium update or 
>conditinal update " etc., until such a granularity is 
>available, we should use the existing documented mechanisms. 
>This is the reason I think it would be expedient to seek the 
>advice of IESG in this matter.

My position is very simple:
What part of RFC 793 is no longer correct?  Which text is no
longer accurate in RFC 793?

With ECN, it's very clear, the answer is "the 2 reserved bits
are not reserved anymore".  With tcpsecure, the answer is also
very clear: "nothing".  You need to point to some part of 793
that is actually updated and not just alternatively defined,
IMO.  If 2581, 1323, and others don't update 793, then I don't
see how tcpsecure can have any valid claim to.

That's just my personal opinion, though.
tcpm mailing list