Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
 by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05436
 for <ipsec-archive@lists.ietf.org>; Tue, 25 Mar 2003 16:47:14 -0500 (EST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11335
 Tue, 25 Mar 2003 14:16:07 -0500 (EST)
Message-Id: <200303251919.h2PJJKaj029079@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@east.sun.com>
To: "jpickering@creeksidenet.com" <jpickering@creeksidenet.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Text suggestion on computing keymat for rekey 
In-Reply-To: Your message of "Tue, 25 Mar 2003 13:24:15 EST."
 <3E809ECF.7070902@creeksidenet.com> 
Reply-to: sommerfeld@east.sun.com
Date: Tue, 25 Mar 2003 14:19:20 -0500
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

> "For purposes of computing keying material for the rekeyed SA, the 
> original initiator
> of the SA is to be considered initiator of the rekeyed SA."

I may well have been part of the same hallway discussion.  One of the
other conclusions that this group came to was that it was somewhere
between extremely helpful and absolutely necessary to add an attribute
in the negotiation which specifically called out *which* SA was being
rekeyed/replaced.  (All you'd need is the SPI of the previous SA).

I hope this also isn't controversial.

						- Bill