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

"Anantha Ramaiah (ananth)" <> Tue, 30 September 2008 20:47 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 907C43A6BE7; Tue, 30 Sep 2008 13:47:28 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 175AD3A6BE7 for <>; Tue, 30 Sep 2008 13:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.371
X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h1G1e+PFGXv5 for <>; Tue, 30 Sep 2008 13:47:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1BC053A6BE5 for <>; Tue, 30 Sep 2008 13:47:26 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,339,1220227200"; d="scan'208";a="22413628"
Received: from ([]) by with ESMTP; 30 Sep 2008 20:47:48 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m8UKlm0X016488; Tue, 30 Sep 2008 13:47:48 -0700
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m8UKlmxb005491; Tue, 30 Sep 2008 20:47:48 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Sep 2008 13:47:47 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 30 Sep 2008 13:47:44 -0700
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
Thread-Index: AckjFO+lNnhV8IygRWO9tjxdRj/8mQAASsbwAAIBL4AAANa5QAAA1GwwAASOJxA=
References: <> <><><><><><><><> <>
From: "Anantha Ramaiah (ananth)" <>
To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <>, David Borman <>, Lars Eggert <>,
X-OriginalArrivalTime: 30 Sep 2008 20:47:47.0972 (UTC) FILETIME=[CC066C40:01C9233D]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2469; t=1222807668; x=1223671668; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20[tcpm]=20another=20review=20of=20draft- ietf-tcpm-tcpsecure[-10] |Sender:=20; bh=6tw4KQ3qtIhMtMkwO8eYaLWS/yEPjVfqDMeHCNC762g=; b=Lquz15ZzOiFhdTEzOD+Jq786usQLrKe50hCULvt9QvvPk2zvSVBEcX9Fwy g2DaRiagoWztvKqavntFaKRD8+kY6GTDnijlJ48KAAckN559mNq4FKvX++t1 f410xEUWL7;
Authentication-Results: sj-dkim-2;; dkim=pass ( sig from verified; );
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


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

So, in other words, are we saying that only changes to TCP header is considered as an update and not the stuff that changes the semantics ? This is probably a general question w.r.t updates, nothing specific to 793 update.

"Alternatively defined" is also trying to change the RFC 793 semantics i.e, in the current case segment processing rules w.r.t RST, SYN and Data. 

FWIW, 1323 talks "TCP extensions for High performance" about window scaling ( a new TCP option), timestamps ( a new TCP option) and PAWS (which is possible only when you use timestamps), these don't update RFC 793 and just supplements it, IMO.

RFC 1122 standarided the TCP congestion control algorithms and not RFC 793. So if it all 2581 has to update something it had to be 1122 not 793.

> That's just my personal opinion, though.

Sure, my opinion is similar but I am confused with the meaning and applicability of the term "updates". We need to have a consistent story. That is the reason I suggested seeking IESG advice in this matter.

> _______________________________________________
> tcpm mailing list
tcpm mailing list