[IPsec] Closing #25

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 24 November 2009 01:18 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55853A693A for <ipsec@core3.amsl.com>; Mon, 23 Nov 2009 17:18:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.959
X-Spam-Level:
X-Spam-Status: No, score=-5.959 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 chF3Bj72-gb6 for <ipsec@core3.amsl.com>; Mon, 23 Nov 2009 17:18:39 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C41593A67FA for <ipsec@ietf.org>; Mon, 23 Nov 2009 17:18:39 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAO1IV1I046138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 18:18:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240849c730e28d02c4@[10.20.30.158]>
In-Reply-To: <349076FF-487D-4B6C-91EB-1E845B2303F6@checkpoint.com>
References: <p06240849c7039304f1d1@[10.20.30.158]> <349076FF-487D-4B6C-91EB-1E845B2303F6@checkpoint.com>
Date: Mon, 23 Nov 2009 17:09:15 -0800
To: Yoav Nir <ynir@checkpoint.com>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: IPsecme WG <ipsec@ietf.org>
Subject: [IPsec] Closing #25
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Nov 2009 01:18:41 -0000

At 9:46 AM +0200 10/21/09, Yoav Nir wrote:
>A few lines above this section it already says "If the responder's policy allows it to accept the first selector of TSi and TSr, then the responder MUST narrow the traffic selectors to a subset that includes the initiator's first choices."
>
>So there is a MUST requirement to select the initiator's first choice (if possible), so I don't think the SHOULD and MAY are appropriate here. The way I read this section, it only clarifies what to do if the initiator traffic selector (first or not) is too broad. In that case, we shouldn't mention the initiator's choices.
>
>On Oct 20, 2009, at 6:19 PM, Paul Hoffman wrote:
>
>>Issue #25, Choice of the right TS when narrowing
><snip/>
>>Proposed change:
>>  When narrowing is done, there may be several subsets that are
>>  acceptable but their union is not.  In this case, the responder
>>  SHOULD select the initiator's first choice (to be interoperable
>>  with RFC 4306), but MAY arbitrarily select any of them,
>>  and MAY include an
>>  ADDITIONAL_TS_POSSIBLE notification in the response.

God call. I have closed #25 without making any change.

--Paul Hoffman, Director
--VPN Consortium