<wearing AD hat> FYI: Tim will be the responsible AD for this draft (since I was listed as a co-author in an earlier version); he will hopefully do his AD evaluation soon (and might consider these as IETF Last Call comments).
<not wearing any hats> There's one remaining issue that was changed due to WGLC comments, but the result isn't quite what it IMHO should be. When doing redirection during IKE_AUTH, in some situations the IKE_AUTH response with the REDIRECT is the last message between the client and gateway (and the IKE_SA is not used, and cannot be used, for any other exchanges after that). In other situations, it *is* used for (at least) one additional exchange (Informational exchange with DELETE payload). When the Informational exchange is needed/allowed and when not is not totally random, but I don't expect that any readers would understand it (I do know Tero can explain it :-). It also creates room for confusion whether the REDIRECT is just a "hint" and the IKE_SA could still be used for other exchanges, too. I would suggest we get rid of this unnecessary complexity, and simply say that when you do REDIRECT during IKE_AUTH, no more exchanges are done (on that IKE_SA) after the REDIRECT is sent. There's also one place that is probably correct, but would benefit from some clarification. Section 5 says: "When the client receives this message, it MUST send an empty message as an acknowledgement. Until the client responds with an acknowledgement, the gateway SHOULD re-transmit the redirect INFORMATIONAL message as described in [2]." The MUST and SHOULD here give the impression that this Informational exchange is somehow special, and treated differently from ordinary Informational exchanges. As far as I can tell, it's *not* meant to be special, and this text isn't meant to specify any new requirements. I'd suggest rephrasing this something like "As in any other INFORMATIONAL exchange, the clients sends a response (usually empty), and the gateway retransmits the request if it doesn't receive a response." BTW, in Section 10, "expert review" probably should be "Expert Review as specified in [RFC5226]". Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
