Re: [tcpm] TCP-AO review comments.

"Eddy, Wesley M. (GRC-RCN0)[VZ]" <> Mon, 04 August 2008 15:01 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 43C9128C292; Mon, 4 Aug 2008 08:01:16 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 343E428C2D0 for <>; Mon, 4 Aug 2008 08:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.957
X-Spam-Status: No, score=-5.957 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q3X0wG-rlg23 for <>; Mon, 4 Aug 2008 08:01:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4391128C292 for <>; Mon, 4 Aug 2008 08:01:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 44A4E3281C1; Mon, 4 Aug 2008 10:01:40 -0500 (CDT)
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id m74F1dii029303; Mon, 4 Aug 2008 10:01:40 -0500
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 10:01:40 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 04 Aug 2008 10:01:39 -0500
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [tcpm] TCP-AO review comments.
Thread-Index: Acj2PqYX3qAxxnP3SYyfpmXsiUz4SAAAvSvQ
References: <><><> <>
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <>
To: Joe Touch <touch@ISI.EDU>
X-OriginalArrivalTime: 04 Aug 2008 15:01:40.0094 (UTC) FILETIME=[FFDBF9E0:01C8F642]
Subject: Re: [tcpm] TCP-AO review comments.
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

>-----Original Message-----
>From: [] On 
>Behalf Of Joe Touch
>Sent: Monday, August 04, 2008 10:29 AM
>Hash: SHA1
>Hi, Ananth,
>Just a few remaining points to clarify...
>Anantha Ramaiah (ananth) wrote:
>|> | #1
>|> |    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?
>| Sure, ok let me rephrase the question here : "TCP MD5 option would
>| continue to exist and should be supported for quite sometime" Does
>| "obselete" allow this fact?
>My impression is that it does, i.e., it recommends replacement, but
>doesn't prevent it being used for legacy purposes.
>< I would have preferred "Updates/Revises"
>| which gives some leeway for co-existence to support legacy.
>We're not changing anything in TCP MD5, so we neither update 
>nor revise it.
>It seems like those of us replying are in agreement on this overall
>point, but don't quite know what the best language to use is (if others
>want to debate that point, though, please do). It might be 
>useful to ask
>the IESG for advice (which I will do).

I think that "obsoletes" is correct.  There are problems with 2385, and
AO is the solution that we're creating to replace it.  We *do* want to
discourage 2385 use when AO is ready, so obsoleting seems like the right
thing to do.  Of course someone could still use 2385; the status of a
document has no power over what's in an implementation or enabled in a
deployment, we just don't want to encourage it.

tcpm mailing list