Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-labeled-ipsec-11: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-labeled-ipsec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. It is easy to read and can be useful is specific use cases. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## SPD interaction While this I-D is about IKEv2, there is little mention of interaction with IPsec SPD beside "pass the TS to the SPD". I wonder whether there must be more than a simple "pass to the SPD" operation on the responder side as the TS is opaque to IKE, so it is SPD/IPSEC that must decide whether to accept this TS, i.e., it is more than a unilateral "pass" operation. ## Section 2.2 `an Error Notify message containing TS_UNACCEPTABLE MUST be returned.` should the obvious be stated, i.e., the process stop and the proposal is not accepted ? ## No IPv6 examples in 2023 ? Examples are always interesting and useful, but why not using IPv6 ? _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
