Re: [tcpm] TCP-AO review comments.

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?

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