Re: [tcpm] TCP-AO review comments.

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