Re: [tcpm] exegesis of 'Updates' -- was: ... reviewof draft-ietf-tcpm-tcpsecure[-10]

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Wed, 01 October 2008 00:35 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 D9D933A6A2E; Tue, 30 Sep 2008 17:35:27 -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 3789E28C158 for <tcpm@core3.amsl.com>; Tue, 30 Sep 2008 17:35:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.403
X-Spam-Level:
X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 bve+TcbBnp6j for <tcpm@core3.amsl.com>; Tue, 30 Sep 2008 17:35:25 -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 057923A6A2E for <tcpm@ietf.org>; Tue, 30 Sep 2008 17:35:25 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,341,1220227200"; d="scan'208";a="85079773"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 01 Oct 2008 00:35:25 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m910ZPrK023102; Tue, 30 Sep 2008 17:35:25 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m910ZPAQ025425; Wed, 1 Oct 2008 00:35:25 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 17:35:25 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 30 Sep 2008 17:35:24 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC5805DF4DF8@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <48E2B952.6080109@isi.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] exegesis of 'Updates' -- was: ... reviewof draft-ietf-tcpm-tcpsecure[-10]
Thread-Index: AckjVjj2hg+qd60LT8CzKuMibdO8YQAAT8Iw
References: <200809302002.WAA09122@TR-Sys.de> <48E2A86E.5050602@isi.edu> <0C53DCFB700D144284A584F54711EC5805DF4D6F@xmb-sjc-21c.amer.cisco.com> <48E2B952.6080109@isi.edu>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Joe Touch" <touch@ISI.EDU>
X-OriginalArrivalTime: 01 Oct 2008 00:35:25.0403 (UTC) FILETIME=[987D02B0:01C9235D]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3568; t=1222821325; x=1223685325; 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]=20exegesis=20of=20'Updates'=20-- =20was=3A=20...=20reviewof=09draft-ietf-tcpm-tcpsecure[-10] |Sender:=20; bh=Oh5TvDf1auw4C10DZvKGWEqH6HBC8Yr2paJix/rFjrE=; b=nepR98cBIkMJ3D/Wx+vKYYd07LdAArA6k5kY72QgBLMl4FHZkOBrFdtIAf FBWZsT38a8E3M+POweK0sOhdtrVOCKAEC0WMm0/tRAZ1+mKZDYyjFIiW9oY3 SwoKjvGrLpfhnu612GMjMAHS18Nr0fOQPSOYkh/9sOrMk2F28qw2w=;
Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= <ah@tr-sys.de>, tcpm@ietf.org, iesg@iesg.org
Subject: Re: [tcpm] exegesis of 'Updates' -- was: ... reviewof 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

<snip>
 
> 
> > Agreed that the IPR issue might have had some influence w.r.t the 
> > verbiage on the strength of mitigations. Lars Eggert suggested an 
> > applicability statement to be added, we added the same. Not 
> sure why 
> > you are bringing this up now, the IPR issue was beaten to 
> death long 
> > time back.
> 
> It is relevant to the issue of Updates, just as it was during 
> the MUST/SHOULD/MAY discussions.

Atleast this is the first time I am hearing that IPR issue is relevant to the "updates" issue.


> 
> > Again, my current understanding (which is inline with 
> Alfred) is about 
> > "if a draft changes the TCP RFC 793 rules in some way, then it is 
> > considered as an update and we should mark it accordingly 
> upfront for 
> > easy reference purposes" Also, update doesn't mean that "all TCP's 
> > everywhere need to be augumented with the changes". An implementer 
> > would read the mitigations, AS and the strength of recommended 
> > mitigations and would make his/her own choice!
> 
> Others have shown cases where modifications with more 
> ubiquitous utility do not carry the Updates tag. There is no 
> evidence this mod is more deserving of that tag.

The word deserving comes across quite funny to me! Even though modifications with more ubiquitous utility in the past might have missed the "updates" clause (may be due to hindsight), that is a not a reason why we shouldn't use the "updates" tag for a document which actually updates something in 793, IMO. To quote Alfred : [ sorry, it is easier rather than me framing a new sentence altogether]

"
This WG is chartered for the *MAINTENANCE* of TCP.
If you don't want to make that maintenace visible, you are in danger to dismiss your mission (and the mission of the IETF and its Standards Process).  Since RFCs are immutable, RFC Errata and additions to the RFC metadata are the only ways to make an act of maintenance for a document visible at first place."

Well, 1323 and 2581 was mentioned as mods (if that is what you are referring to above). My reply was :

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

Anyways, this is my line of thinking and I haven't heard any convincing arguments so far. 

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