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

"Mitesh Dalal (mdalal)" <mdalal@cisco.com> Wed, 01 October 2008 23:15 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 322783A6A80; Wed, 1 Oct 2008 16:15:17 -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 D06E33A6985 for <tcpm@core3.amsl.com>; Wed, 1 Oct 2008 16:15:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 wPZPhwIh7lOi for <tcpm@core3.amsl.com>; Wed, 1 Oct 2008 16:15:13 -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 A5A573A698F for <tcpm@ietf.org>; Wed, 1 Oct 2008 16:15:13 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,346,1220227200"; d="scan'208";a="85626462"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 01 Oct 2008 23:15:30 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m91NFTfN021949; Wed, 1 Oct 2008 16:15:29 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m91NFThk024188; Wed, 1 Oct 2008 23:15:29 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); Wed, 1 Oct 2008 16:15:29 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 1 Oct 2008 16:15:29 -0700
Message-ID: <13D1EAB852BE194C94773A947138483D061CA91D@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
Thread-Index: Ackj/KOHD9MzS2XBRdmx/SjKs35F6AAHXOww
From: "Mitesh Dalal (mdalal)" <mdalal@cisco.com>
To: "David Borman" <david.borman@windriver.com>, <tcpm@ietf.org>
X-OriginalArrivalTime: 01 Oct 2008 23:15:29.0470 (UTC) FILETIME=[984D75E0:01C9241B]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4771; t=1222902930; x=1223766930; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mdalal@cisco.com; z=From:=20=22Mitesh=20Dalal=20(mdalal)=22=20<mdalal@cisco.co m> |Subject:=20RE=3A=20[tcpm]=20another=20review=20of=20draft- ietf-tcpm-tcpsecure[-10] |Sender:=20; bh=AdbpUDyMFC4z/BanxeBzv2kDyiYvdsYEPr2gUofqOpQ=; b=drrS70FjzNK/X3JC/eEDSdulxm691gEDhzTqCbyvaJnW0EQinhuaa2Qi87 TQ2pVGPHGnOKRREpBmrVul54NCjUIjEB7ujEWXyUTmQQ/DW65CS6XlCG4nGY m5rt33ZXiS;
Authentication-Results: sj-dkim-2; header.From=mdalal@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
Cc: =?iso-8859-1?Q?Alfred_H=CEnes?= <ah@tr-sys.de>, Joe Touch <touch@isi.edu>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, Randy Stewart <randall@lakerest.net>, "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" <Wesley.M.Eddy@nasa.gov>
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

vote for updates. 

I personally feel we are reading too much into the updates lingo. 
I didn't care one way or the other until somebody (Alfred ?) brought 
this up. Given that this is standards track document, the entire 
interne community will be well served if we clearly highlight where
we are coming from. Updates in my mind does not mean a tcp V2 
nor it means MUST implement. It simply means a new piece of 
information found that concerns a base spec and sheds some new
light on it.


Thanks
Mitesh 

> -----Original Message-----
> From: David Borman [mailto:david.borman@windriver.com] 
> Sent: Wednesday, October 01, 2008 12:33 PM
> To: tcpm@ietf.org
> Cc: Eddy, Wesley M. (GRC-RCN0)[VZ]; Anantha Ramaiah (ananth); 
> Lars Eggert; Alfred HÎnes; Mitesh Dalal (mdalal); Randy 
> Stewart; Joe Touch
> Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
> 
> Ok, Wes and I count four opinions against and two opinions for having
> "Updates: 793" in the header of tcpsecure.  Unless other 
> folks chime in, the resolution we see is:
> 
> 1) "Updates: 793" is not put in the header of tcpsecure
> 2) When we send tcpsecure up to the IESG, we will note this 
> issue and the discussion, and if the IESG feels that is 
> appropriate to have
> "Updates: 793" in the header, then it can be added in.
> 
> We think everyone has been heard and understood, but don't 
> see this conversation coming to full agreement.
> 
> 			-David Borman & Wes Eddy, TCPM co-chairs
> 
> 
> On Sep 30, 2008, at 5:03 PM, Joe Touch wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> >
> > Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
> >>> -----Original Message-----
> >>> From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com]
> >>> Sent: Tuesday, September 30, 2008 1:47 PM
> >>> To: Eddy, Wesley M. (GRC-RCN0)[VZ]; David Borman; Lars Eggert; 
> >>> tcpm@ietf.org
> >>> Cc: Alfred HÎnes; Mitesh Dalal (mdalal); 
> randall@lakerest.net; ext 
> >>> Joe Touch
> >>> Subject: RE: [tcpm] another review of 
> draft-ietf-tcpm-tcpsecure[-10]
> >>>
> >>> Wes,
> >>>
> >>>>
> >>>> 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.
> >>> 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.
> >>
> >> That's just my personal opinion, though.
> >
> >
> > This makes sense to me.
> >
> > Joe
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iEYEARECAAYFAkjioioACgkQE5f5cImnZrvyfACgk+tXUy6Q1TdshUpvN9Zixv/i
> > 2FEAoNoBwdYFzVM+r0wokwbAaJKLJ3PI
> > =q5ru
> > -----END PGP SIGNATURE-----
> 
> 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm