Re: [tcpm] TCP-AO review comments.

[Chandrashekhar Appanna <[e-mail]>]

On Mon, Aug 04, 2008 at 10:01:39AM -0500, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
> >-----Original Message-----
> >From: [e-mail] [mailto:[e-mail]] On 
> >Behalf Of Joe Touch
> >Sent: Monday, August 04, 2008 10:29 AM
> >
> >-----BEGIN PGP SIGNED MESSAGE-----
> >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.
>

  Not sure if this will obselete that.. this is a new option with different
  goals and we are not even sure if at this point how much consensus there
  is about moving AO forward.. there is much discussion on the keying aspects,
  the design team seems to be just one person speaking up mostly; and
  given the comments from other design team members at the mike at the ietf
  I would not be in favour of making AO obselete the other method.. like you
  say the status of the document has no power and therefore it is better
  to not think it has some if it does not line up ;).. forcing a document
  through without the implied working code and rough consensus may end up
  doing more harm to the doc itself..

  Rgds,
  Chandra. 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm