Paul Wouters has entered the following ballot position for draft-ietf-ipsecme-iptfs-14: Yes
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-iptfs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Security AD review of draft-ietf-ipsecme-iptfs-14 CC @paulwouters ## COMMENTS ### users don't implement? A good choice for the size of this window depends on the amount of misordering the user may normally experience. This sentence does not help the implementer, nor the user. Users only experience "works well", "is slow", "does not work" :P ### tunnel vs SA 2.4. Modes of Operation Just as with normal IPsec/ESP tunnels, AGGFRAG tunnels are unidirectional. Bidirectional IP-TFS functionality is achieved by setting up 2 AGGFRAG tunnels, one in either direction. An AGGFRAG tunnel used for IP-TFS can operate in 2 modes, a non- congestion-controlled mode and congestion-controlled mode. Do you mean to say IPsec SA's are unidirectional? Because when you talk about a "tunnel", that to me feels bidirectional so it reads as if you need two IPsec tunnels (eg 4 IPsec SAs) but I think you mean to say that the inbound and outbound IPsec SA both need to enable AGGFRAG. That is, you need to decide on whether an "AGGFRAG tunnel" is a set of two IPsec SAs or not and then use the term consistently. Or perhaps call it an "AGGFRAG IPsec SA" ? _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
