Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08

Paul Hoffman <paul.hoffman@vpnc.org> Mon, 08 March 2010 15:17 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 F3FDB3A6A0A; Mon, 8 Mar 2010 07:17:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.94
X-Spam-Level:
X-Spam-Status: No, score=-5.94 tagged_above=-999 required=5 tests=[AWL=0.106, 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 NrBJr9RsvrEA; Mon, 8 Mar 2010 07:17:32 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D2B343A6A06; Mon, 8 Mar 2010 07:17:31 -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 o28FHXuC089998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 08:17:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240803c7bac47aaf65@[10.20.30.158]>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758482FF391@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB7758482FF051@NOK-EUMSG-01.mgdnok.nokia.com> <p06240810c7b8ad71932e@[10.20.30.158]> <808FD6E27AD4884E94820BC333B2DB7758482FF391@NOK-EUMSG-01.mgdnok.nokia.com>
Date: Mon, 08 Mar 2010 07:17:33 -0800
To: Pasi.Eronen@nokia.com, ietf@ietf.org, ipsec@ietf.org
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08
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: Mon, 08 Mar 2010 15:17:34 -0000

At 8:16 AM +0100 3/8/10, <Pasi.Eronen@nokia.com> wrote:
>Well, this depends on whether you think Section 1.7 should list
>textual changes in the document, or clarification/changes to the
>protocol.
>
>IMHO, it should be the latter, but I see that currently it's really
>listing the textual changes (even when they clearly don't have any
>impact on the protocol); so perhaps listing these separately is
>consistent with that...

The problem with making this list more conceptual (as both you and Tero have requested) is that doing so may help future implementers but can miss context that is important to a current implementer who needs to change their implementation. In this particular example, we have one change that affects two very different parts of the document, and someone who implemented by reading RFC 4306 (instead of knowing it instinctively like you and Tero) might really need to see exactly which bits *of the spec* are changing to decide which bits of their code is changing.

I will try to come up with a way to cover the conceptual change as well, but really am loath to remove the section references in the change description.

--Paul Hoffman, Director
--VPN Consortium