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

David Borman <david.borman@windriver.com> Thu, 02 October 2008 19:12 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 4841A28C261; Thu, 2 Oct 2008 12:12:53 -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 CABCF28C261 for <tcpm@core3.amsl.com>; Thu, 2 Oct 2008 12:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.561
X-Spam-Level:
X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 fVT+Abj-gsKr for <tcpm@core3.amsl.com>; Thu, 2 Oct 2008 12:12:50 -0700 (PDT)
Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id AEEC928C0EE for <tcpm@ietf.org>; Thu, 2 Oct 2008 12:12:50 -0700 (PDT)
Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m92JC3SD025781; Thu, 2 Oct 2008 12:12:03 -0700 (PDT)
Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 12:12:03 -0700
Received: from dab-restive.wrs.com ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 12:12:02 -0700
Message-Id: <3FAB3E97-F849-46C8-B81E-22060D601D8D@windriver.com>
From: David Borman <david.borman@windriver.com>
To: tcpm@ietf.org
In-Reply-To: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 2 Oct 2008 14:12:00 -0500
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> <48E2A22A.8000209@isi.edu> <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com>
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 02 Oct 2008 19:12:03.0359 (UTC) FILETIME=[C0CB8AF0:01C924C2]
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>, "Mitesh Dalal \(mdalal\)" <mdalal@cisco.com>, "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-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

At this point I count 5 for (Alfred, Anantha, Mitesh, Murali &  
Stefanos) and 5 against (Lars, Joe, David, Wes & Ted).  We have  
conflicting interpretations of what "Updates" means; what is written  
down in the RFC index and in RFC 2223, what as been done in practice,  
and personal opinions.  I don't see those converging on the TCPM  
mailing list.  So, whether or not "Updates: 793" is put into the  
draft, this issue will be explicitly noted when it is sent up to the  
IESG.
			-David Borman


On Oct 1, 2008, at 2:33 PM, David Borman wrote:

> 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

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