Éric Vyncke has entered the following ballot position for draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below one blocking DISCUSS point, some non-blocking COMMENT points, and some nits. I support Erik Kline's DISCUSS points as well as Ben Kaduk's DISCUSS point about vendor-specific. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 5 -- Isn't there also the 'load sharing by IPSEC-only NSF' a use case ? Where simple ECMP could split traffic to several IPSec-only NSFs configured with the same parameters (SADB, SPD, ...) (anti-reply being probably impossible to offer though) -- Section 6 -- It seems that this section sometimes uses the term 'model' instead of 'module'. -- Section 6.1 -- I would have preferred to use 'local-prefix' rather than 'local-subnet' as the latter is old looking IPv4 subnet. The "state" part does not seem to contain the current state of the IKE finite state machine, is it on purpose ? -- Section 8.2 -- As IKEv2 provides "perfect forward secrecy" should this section mandating the use of a secure channel between SDN and the NSF also with "perfect forward secrecy" and same reasoning for the encryption algorithms of course. _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
