Re: Making IPsec *not* mandatory in Node Requirement

James Carlson <james.d.carlson@sun.com> Thu, 28 February 2008 13:45 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ietfarch-ipv6-archive@core3.amsl.com
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649563A6B4C; Thu, 28 Feb 2008 05:45:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.937
X-Spam-Level:
X-Spam-Status: No, score=-0.937 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W11UfzE7zghW; Thu, 28 Feb 2008 05:44:57 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E20C13A6E75; Thu, 28 Feb 2008 05:44:57 -0800 (PST)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD703A6961 for <ipv6@core3.amsl.com>; Thu, 28 Feb 2008 05:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddatprwLQZt9 for <ipv6@core3.amsl.com>; Thu, 28 Feb 2008 05:44:51 -0800 (PST)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id A2E363A6A40 for <ipv6@ietf.org>; Thu, 28 Feb 2008 05:44:47 -0800 (PST)
Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1SDieVP013491 for <ipv6@ietf.org>; Thu, 28 Feb 2008 13:44:40 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m1SDie7w059326 for <ipv6@ietf.org>; Thu, 28 Feb 2008 08:44:40 -0500 (EST)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1SDiVbq026053; Thu, 28 Feb 2008 08:44:31 -0500 (EST)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1SDiUIL026050; Thu, 28 Feb 2008 08:44:30 -0500 (EST)
MIME-Version: 1.0
Message-ID: <18374.47806.354120.554370@gargle.gargle.HOWL>
Date: Thu, 28 Feb 2008 08:44:30 -0500
From: James Carlson <james.d.carlson@sun.com>
To: Julien Laganier <julien.IETF@laposte.net>
Subject: Re: Making IPsec *not* mandatory in Node Requirement
In-Reply-To: <200802281004.34603.julien.IETF@laposte.net>
References: <200802261618.m1QGIXqt016372@cichlid.raleigh.ibm.com> <1cc401c8792a$5fa6bf90$1ef43eb0$@net> <200802271714.m1RHED68018076@cichlid.raleigh.ibm.com> <200802281004.34603.julien.IETF@laposte.net>
X-Mailer: VM 7.01 under Emacs 21.3.1
Cc: Thomas Narten <narten@us.ibm.com>, ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Julien Laganier writes:
> On Wednesday 27 February 2008, Thomas Narten wrote:
> > We'll never get them to rely on IPsec, at least not until its much
> > more widely available/useable. 
> 
> Agree. But I think the availability part can be helped by keeping IPsec 
> mandatory (so that it gets in more and more OS's), while the usability 
> part can be helped by getting the BTNS WG to deliver its APIs (so that 
> applications can finally start using IPsec).

You get exactly that same level of goodness with a BCP 14 "SHOULD."
The only difference is that "MUST" causes implementors with differing
fundamental marketing considerations to toss the whole requirements
RFC out on its ear -- because it mandates something that (in their
view) ought not be done or perhaps simply _cannot_ be done with
available resources.

MUST doesn't actually cause any more implementations to appear in
comparison to SHOULD.  I think your argument would work, though, if we
were discussing SHOULD versus MAY.

-- 
James Carlson, Solaris Networking              <james.d.carlson@sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------