Hi Vijay, "It SHOULD delete ... using the same procedure as Sec. 6"?
Clarity of prose at the expense of the beauty :-(
Thanks,
Yaron
> -----Original Message-----
> From: Vijay Devarapalli [mailto:vi...@wichorus.com]
> Sent: Tuesday, May 05, 2009 9:00
> To: Yaron Sheffer; pasi.ero...@nokia.com; ipsec@ietf.org
> Subject: RE: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
>
> Hi Yaron,
>
> > > The current text assumes that the IKE SA is created and needs to be
> > > deleted.
> > > I don't think we need to show the INFORMATIONAL exchange.
> > We are not
> > > modifying anything in the delete procedure. We currently have the
> > > following text
> > >
> > > When the client
> > > receives the IKE_AUTH response with the REDIRECT
> > payload, it SHOULD
> > > delete the existing IKEv2 security association with the gateway.
> > >
> > > Isn't this sufficient?
> > >
> > No, it's not sufficient. Unfortunately the word "delete" is
> > ambiguous, and people can understand it either as "silently
> > delete" or "delete and inform the peer". So I'd rather have
> > "it SHOULD delete ... using an Informational exchange."
>
> The previous section already says this.
>
> Once the client sends an acknowledgement to the gateway, it SHOULD
> delete the existing security associations with the old gateway by
> sending an Informational message with a DELETE payload. The gateway
> MAY also decide to delete the security associations without any
> signaling from the client, again by sending an Informational message
> with a DELETE payload.
>
> I guess you want this text repeated in section 6 too (?)
>
> Vijay
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
