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

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Tue, 30 September 2008 20:47 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 907C43A6BE7; Tue, 30 Sep 2008 13:47:28 -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 175AD3A6BE7 for <tcpm@core3.amsl.com>; Tue, 30 Sep 2008 13:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.371
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1G1e+PFGXv5 for <tcpm@core3.amsl.com>; Tue, 30 Sep 2008 13:47:26 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 1BC053A6BE5 for <tcpm@ietf.org>; 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 sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 30 Sep 2008 20:47:48 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8UKlm0X016488; Tue, 30 Sep 2008 13:47:48 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8UKlmxb005491; Tue, 30 Sep 2008 20:47:48 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com 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: <0C53DCFB700D144284A584F54711EC5805DF4C45@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <B5A5E01F9387F4409E67604C0257C71E5603CD@NDJSEVS25A.ndc.nasa.gov>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
Thread-Index: AckjFO+lNnhV8IygRWO9tjxdRj/8mQAASsbwAAIBL4AAANa5QAAA1GwwAASOJxA=
References: <200808140650.IAA05627@TR-Sys.de> <0C53DCFB700D144284A584F54711EC5805DF435A@xmb-sjc-21c.amer.cisco.com><B35986E6-D8D7-4A9E-B8AB-3DB2E5C3FA29@nokia.com><48E110DE.8050903@isi.edu><724ED3DF-B4E5-4FF8-93BF-5B84688CC940@nokia.com><3B570CE3-309B-4473-9A19-99905A93986A@windriver.com><0C53DCFB700D144284A584F54711EC5805DF4A3C@xmb-sjc-21c.amer.cisco.com><B5A5E01F9387F4409E67604C0257C71E56038C@NDJSEVS25A.ndc.nasa.gov><0C53DCFB700D144284A584F54711EC5805DF4AE2@xmb-sjc-21c.amer.cisco.com> <B5A5E01F9387F4409E67604C0257C71E5603CD@NDJSEVS25A.ndc.nasa.gov>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <Wesley.M.Eddy@nasa.gov>, "David Borman" <david.borman@windriver.com>, "Lars Eggert" <lars.eggert@nokia.com>, <tcpm@ietf.org>
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; d=cisco.com; i=ananth@cisco.com; 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; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
Cc: =?iso-8859-1?Q?Alfred_H=CEnes?= <ah@tr-sys.de>, "Mitesh Dalal \(mdalal\)" <mdalal@cisco.com>, randall@lakerest.net, ext Joe Touch <touch@isi.edu>
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

 

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

-Anantha
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm