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

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