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

>-----Original Message-----
>From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On 
>Behalf Of Anantha Ramaiah (ananth)
>Sent: Tuesday, September 30, 2008 12:43 PM
>
>David/Wes,
>
>I don't intend to prolong this discussion, but the current 
>stance comes across very incurrate.
>
>Based on the example which you gave narrated below :
>
>RFC 3168 used up 2 reserved bits in the TCP header, and hence 
>updated the RFC 793. Now RFC 3168 is optional. This doesn't 
>prevent the fact that "updates" can be used as a qualifier. 
>
>With TCP secure, it changes the processing rules of certain 
>segments (algorithm), so strictly speaking it does update RFC 
>793. It is optional since none of the conditions is MUST and 
>also there is an AS in place. Here you can't use "updates" 
>since that becomes too strong a word! This beats me.
>
>It appears that we are reading too much into the word 
>"updates" rather than acknowledging its simplicity, i.e, it is 
>just a quick reference point.
>
>So, I guess I am confused as to how and where the lines are 
>drawn. Hence, I think that it would be expedient to seek the 
>advice of IESG as well in this matter. Isn't a good thing ? 

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.
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm