Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08
Tero Kivinen <kivinen@iki.fi> Mon, 08 March 2010 15:43 UTC
Return-Path: <kivinen@iki.fi>
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 689DB3A6A24; Mon, 8 Mar 2010 07:43:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6]
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 toUTtJZWCRLN; Mon, 8 Mar 2010 07:43:13 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF743A6A1F; Mon, 8 Mar 2010 07:43:12 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o28FhCNI000387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 17:43:12 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o28FhBfB015673; Mon, 8 Mar 2010 17:43:11 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <19349.6926.978794.772035@fireball.kivinen.iki.fi>
Date: Mon, 08 Mar 2010 17:43:10 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <p06240803c7bac47aaf65@[10.20.30.158]>
References: <808FD6E27AD4884E94820BC333B2DB7758482FF051@NOK-EUMSG-01.mgdnok.nokia.com> <p06240810c7b8ad71932e@[10.20.30.158]> <808FD6E27AD4884E94820BC333B2DB7758482FF391@NOK-EUMSG-01.mgdnok.nokia.com> <p06240803c7bac47aaf65@[10.20.30.158]>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 5 min
X-Total-Time: 5 min
Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, ietf@ietf.org
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:43:14 -0000
Paul Hoffman writes: > 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. As an implementor I disagree with you on that. > 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. Yes that change changes two locations of the text, but only one location in the implementation. Thus for someone who is doing this change for their implementation it would be important to understand that this change is actually just one code change, not two. Also the change is most likely going to be in the policy enforing part than in the actual exchange handling code (1.3.2) or the SKEYSEED calculation part. The implementation simply needs to enforce the IKE SA rekey policy so that Diffie-Hellman is not optional and that is only change they need to do in the code. They already have to calculate the SKEYSEED (most likely with or without the g^ir (new)), and they already have the code to parse KEi and KEr (generic code). > 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. -- kivinen@iki.fi
- [IPsec] IETFLC comments for draft-ietf-ipsecme-ik… Pasi.Eronen
- Re: [IPsec] IETFLC comments for draft-ietf-ipsecm… Paul Hoffman
- Re: [IPsec] IETFLC comments for draft-ietf-ipsecm… Pasi.Eronen
- Re: [IPsec] IETFLC comments for draft-ietf-ipsecm… Tero Kivinen
- Re: [IPsec] IETFLC comments for draft-ietf-ipsecm… Paul Hoffman
- Re: [IPsec] IETFLC comments for draft-ietf-ipsecm… Tero Kivinen
- [IPsec] IETFLC comments for draft-ietf-ipsecme-ik… Keith Welter
- Re: [IPsec] IETFLC comments for draft-ietf-ipsecm… Yoav Nir
- Re: [IPsec] IETFLC comments for draft-ietf-ipsecm… V Jyothi-B22245