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

-----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