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

>-----Original Message-----
>From: Joe Touch [mailto:touch@ISI.EDU] 
>Sent: Thursday, October 02, 2008 1:19 PM
>
>FWIW, we're dealing not only with what RFC2223 says in this regard, but
>the current IETF culture of when to use "updates".
>
>As I've noted, there are other extensions to TCP that are more 
>"updates"
>than this. We have a roadmap document to more clearly explain the
>relationship of components to 793; when that document is updated,
>tcpsecure should be added to that. Given the complexity of that
>document, this label isn't going to help, and IMO will misdirect
>implementers to include this where it wasn't necessary.
>
>I see no reason to lead the charge of changing IETF culture on this
>issue with this document, and specific reasons NOT to use this document
>as the defining case.

It's just my personal opinion, but I'm in full agreement with Joe.
Further, I think that if people are interpreting "updates" as "we
should read and consider implementing", then I'm especially hesitant
to have IPR-encumbered documents "update" 793, as it becomes an
advertisement attached to the base of TCP.

I also feel that tcpsecure is really a stop-gap to handle packets
with spoofed addresses, that could've/should've been caught
elsewhere (RFC 4953) and in more powerful ways (ingress filters,
ipsec, md5, gtsm, etc.) depending on deployment particulars.  It
happens to be a nice and effective stop-gap, but the long-term
solution is to make spoofed packets become nonexistent, at which
point we'll no longer need tcpsecure. 

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