> > > 3) Section 6, 1st paragraph: I think this text needs to be clearer > > about whether an IKE_SA is created or not (current the SHOULDs > > etc. make this somewhat unclear). IMHO if the client will always just > > close the IKE_SA, it doesn't make much sense to create it in the first > > place? But it looks like the intent of the current text might have > > been that the IKE_SA *is* created... If that's the case, then the > > message diagram below this paragraph should also show the > > INFORMATIONAL exchange with Delete payload. > > 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."
Thanks,
Yaron
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
