Re: [tcpm] TCP-AO review comments.

At Wed, 06 Aug 2008 06:58:36 -0700,
Caitlin Bestler wrote:
> 
> Lars Eggert wrote:
> > On 2008-8-2, at 2:16, ext Joe Touch wrote:
> >> |    I have problem with the term "obsoletes 2385" [ I did bring this up
> >> | before] It is going to be a long time before deployments move over to
> >> | the new TCP auth option.
> >>
> >> Practically, "obsoletes" doesn't obsolete anything. It does indicate
> >> that the IETF wants a protocol to be replaced by something else. That
> >> doesn't mean the older one can't be used for legacy support, e.g.,
> >> AFAICT - and that clearly should apply here. If the IESG thinks that
> >> this is consistent with "Obsoltes", would that be OK?
> > 
> > We need to distinguish between one RFC obsoleting another RFC, and 
> > moving an RFC to "historic". Unfortunately, neither is very clearly 
> > defined.
> > 
> > Here's my current thinking: Obsoleting is typically used when one RFC is 
> > a drop-in replacement for another RFC. For example, bug-fix revisions of 
> > an RFC typically obsolete the previous RFC, as do minor 
> > backwards-compatible implementations. That isn't quite the case for AO 
> > and TCP-MD5. AO is a replacement for TCP-MD5, but it isn't a simple 
> > revision or extension of TCP-MD5, it's a new mechanism to provide 
> > similar functionality in a (slightly) different way.
> > 
> > So, my current thinking is that AO should maybe move TCP-MD5 to 
> > "historic". That would indicate that new implementations shouldn't 
> > implement TCP-MD5 and existing ones are encouraged to move away from it. 
> > But this isn't a clear -cut case. Comments?
> > 
> 
> I have always viewed a new TCP-Auth RFC as a drop-in replacement
> for TCP-MD5.
> 
> Basically, this is an application layer problem being foisted upon
> the transport layer. It creates unneeded clutter at the transport
> layer that is not of general utility.
>
> The fact that it is replacing an existing option is the only real
> justification for doing it. Stare decisis is good for constitutional
> law, it makes sense for standards as well.
> 
> But we need to be clear that we are not creating an *additional*
> transport layer encryption solution to solve poor application design,
> we're just replacing an existing problem.

Hmm... I'm not sure I agree with this assessment. What do you think
the application layer problem in question is?

-Ekr

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