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

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Tue, 30 September 2008 16:43 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 697AC3A6A17; Tue, 30 Sep 2008 09:43:13 -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 CE92B3A691E for <tcpm@core3.amsl.com>; Tue, 30 Sep 2008 09:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.306
X-Spam-Level:
X-Spam-Status: No, score=-6.306 tagged_above=-999 required=5 tests=[AWL=0.293, 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 4tVY9k0cojhn for <tcpm@core3.amsl.com>; Tue, 30 Sep 2008 09:43:00 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3B77A28C17B for <tcpm@ietf.org>; Tue, 30 Sep 2008 09:43:00 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,338,1220227200"; d="scan'208";a="84833611"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 30 Sep 2008 16:43:22 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8UGhLEv009594; Tue, 30 Sep 2008 09:43:21 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8UGhLQD026415; Tue, 30 Sep 2008 16:43:21 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Sep 2008 09:43:21 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 30 Sep 2008 09:43:14 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC5805DF4A3C@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <3B570CE3-309B-4473-9A19-99905A93986A@windriver.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
Thread-Index: AckjFO+lNnhV8IygRWO9tjxdRj/8mQAASsbw
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>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "David Borman" <david.borman@windriver.com>, "Lars Eggert" <lars.eggert@nokia.com>, <tcpm@ietf.org>
X-OriginalArrivalTime: 30 Sep 2008 16:43:21.0651 (UTC) FILETIME=[A6377030:01C9231B]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4175; t=1222793002; x=1223657002; c=relaxed/simple; s=sjdkim1004; 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=PDTQ+N8jLuMaoO95Ptn3EYAfOTds4NMVZlIEMW5MZIg=; b=ZKnGqFT3K7erlMH3Y3KohljzBZ41LYdFgH7jSccrMp0/Izoy4t9PBiiBYr xoKy9GSWQ3EI0TxoSq3NGrNvu3W6ZHv1eZuiOBU+ENkK+JeHnU46kb8ity6o U9sv4YZPuBkJ5wz1raq+mwQnXOKCFhMFN7LxGpaytFrfzatChFwXs=;
Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

David/Wes,

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 ? 

$0.02,
-Anantha
> -----Original Message-----
> From: David Borman [mailto:david.borman@windriver.com] 
> Sent: Tuesday, September 30, 2008 8:55 AM
> To: Lars Eggert; tcpm@ietf.org
> Cc: ext Joe Touch; Alfred HÎnes; Anantha Ramaiah (ananth); 
> rrs@cisco.com; Mitesh Dalal (mdalal)
> Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
> 
> (WG co-chair hats on)
> 
> Wes and I discussed this, and we agree with Lars.  "Updates" 
> is generally for things that are now required if you 
> implement the cited spec.  Tcpsecure doesn't fit that 
> criteria, so the "Updates 793"  
> doesn't belong on this document.  As Lars said, this is less 
> than perfect, but it is what we currently have.
> 
> FWIW, I could only find one RFC that has "Updates 793", and 
> that is RFC 3168, "The Addition of Explicit Congestion 
> Notification (ECN) to IP", which allocates two of the 
> reserved flags in the TCP header.
> 
> 			-David & Wes, TCPM WG co-chairs
> 
> On Sep 30, 2008, at 4:43 AM, Lars Eggert wrote:
> 
> > Hi,
> >
> > (individual hat on)
> >
> > On 2008-9-29, at 20:31, ext Joe Touch wrote:
> >> Is it possible that a SHOULD isn't considered a "updates"?
> >
> > RFC2119 language has nothing to do with the "updates" 
> relationship.  
> > It's the applicability that matters.
> >
> > "Updates 793" on document X means "if you implement 793 you 
> also need 
> > to implement X". That is, because "updates" is typically 
> used when a 
> > new document fixes critical bugs in an existing 
> specification or adds 
> > mandatory new functionality.
> >
> > For this document the applicability statement is basically "SHOULD 
> > implement when vulnerable, MAY otherwise". That's a conditional 
> > "updates". Unfortunately, the "updates" header isn't 
> expressive enough 
> > to convey this.
> >
> > We're left with two less-than-optimal choices: Add "updates 793", 
> > which doesn't capture the conditional expressed by the 
> applicability 
> > statement, or omit "updates 793", which is also inaccurate.
> >
> > My reason for suggesting to omit the "updates" - and this is a 
> > personal preference, I'll respect the WG decision and would like to 
> > head other opinions - is that a plain "updates 793" looks 
> like a "you 
> > must implement this when implementing 793", and we had a long 
> > discussion around the applicability statement that seemed 
> to indicate 
> > that the WG didn't want to make this blanket recommendation.
> >
> > Lars
> >
> > PS: As an example, look at the recent RFC5348, which is TFRC. It 
> > obsoletes RFC3448 (which was the old version of TFRC) but it also 
> > updates RFC4342 (DCCP's CCID3), which implements TFRC inside DCCP.
> > The "updates" relationship here means that CCID3 
> implementations must 
> > now (also) implement RFC5348, i.e., the new version of 
> > TFRC._______________________________________________
> > 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