Re: [tcpm] tcpsecure: how strong to recommend?

Mark Allman <mallman@icir.org> Fri, 28 September 2007 18:18 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKQO-0001vD-A0; Fri, 28 Sep 2007 14:18:52 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IbKQM-0001v8-Q7 for tcpm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 14:18:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKQM-0001v0-Gc for tcpm@ietf.org; Fri, 28 Sep 2007 14:18:50 -0400
Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbKQH-0000i6-55 for tcpm@ietf.org; Fri, 28 Sep 2007 14:18:50 -0400
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l8SIIPUt026887; Fri, 28 Sep 2007 11:18:25 -0700
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id EC4F1FFF008; Fri, 28 Sep 2007 14:18:19 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 42E852A9F9F; Fri, 28 Sep 2007 14:17:11 -0400 (EDT)
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
From: Mark Allman <mallman@icir.org>
Subject: Re: [tcpm] tcpsecure: how strong to recommend?
In-Reply-To: <0C53DCFB700D144284A584F54711EC5804051D95@xmb-sjc-21c.amer.cisco.com>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Car Phone
MIME-Version: 1.0
Date: Fri, 28 Sep 2007 14:17:11 -0400
Message-Id: <20070928181711.42E852A9F9F@lawyers.icir.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: tcpm@ietf.org, David Borman <david.borman@windriver.com>, Fernando Gont <fernando@gont.com.ar>
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0571544286=="
Errors-To: tcpm-bounces@ietf.org

Anantha-

I have to say I am pretty drained from reading this thread and really
don't know if we have consensus on anything or are driving towards
developing it.

The one thing that really confuses me in this discussion is the
statements like this:

> Since, all these discussions about started due to TCP secure, let me
> use the same as an example. There is nothing wrong in making all
> mitigations SHOULD since the "very good reason" can be one of :-

It really seems to me that you are equating MAY and SHOULD.  It seems
like this is saying that implementers can come up with any reason to not
implement tcpsecure if we tag these with a SHOULD.  I think I understand
a number of other people's distinctions between MAY and SHOULD, but I
cannot figure out how you differentiate them and therefore I cannot
figure out why you think they ought to be SHOULD and not MAY.

allman



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