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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 661BF28C115; Tue, 30 Sep 2008 10:06:14 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFE8528C115 for <>; Tue, 30 Sep 2008 10:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.901
X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OwMgMzZm-Do6 for <>; Tue, 30 Sep 2008 10:06:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E80F33A6A32 for <>; Tue, 30 Sep 2008 10:06:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 411B2A818A; Tue, 30 Sep 2008 12:06:24 -0500 (CDT)
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id m8UH6Rec029338; Tue, 30 Sep 2008 12:06:27 -0500
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Sep 2008 12:06:28 -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:06:28 -0500
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
Thread-Index: AckjFO+lNnhV8IygRWO9tjxdRj/8mQAASsbwAAIBL4A=
References: <> <><><><><> <>
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <>
To: "Anantha Ramaiah (ananth)" <>, David Borman <>, Lars Eggert <>,
X-OriginalArrivalTime: 30 Sep 2008 17:06:28.0739 (UTC) FILETIME=[E0FC4530:01C9231E]
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="us-ascii"
Content-Transfer-Encoding: 7bit

>-----Original Message-----
>From: [] On 
>Behalf Of Anantha Ramaiah (ananth)
>Sent: Tuesday, September 30, 2008 12:43 PM
>I don't intend to prolong this discussion, but the current 
>stance comes across very incurrate.
>Based on the example which you gave narrated below :
>RFC 3168 used up 2 reserved bits in the TCP header, and hence 
>updated the RFC 793. Now RFC 3168 is optional. This doesn't 
>prevent the fact that "updates" can be used as a qualifier. 
>With TCP secure, it changes the processing rules of certain 
>segments (algorithm), so strictly speaking it does update RFC 
>793. It is optional since none of the conditions is MUST and 
>also there is an AS in place. Here you can't use "updates" 
>since that becomes too strong a word! This beats me.
>It appears that we are reading too much into the word 
>"updates" rather than acknowledging its simplicity, i.e, it is 
>just a quick reference point.
>So, I guess I am confused as to how and where the lines are 
>drawn. Hence, I think that it would be expedient to seek the 
>advice of IESG as well in this matter. Isn't a good thing ? 

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.
tcpm mailing list