Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-iptfs-14: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I supporting Lars' DISCUSS points, especially that around Section 2.4.1, paragraph 3: The packet send rate is constant and is not automatically adjusted regardless of any network congestion (e.g., packet loss). For similar reasons as given in [RFC7510] the non-congestion- controlled mode should only be used where the user has full administrative control over the path the tunnel will take. This is required so the user can guarantee the bandwidth and also be sure as to not be negatively affecting network congestion [RFC2914]. In this case, packet loss should be reported to the administrator (e.g., via syslog, YANG notification, SNMP traps, etc.) so that any failures due to a lack of bandwidth can be corrected. This is a largely unrealistic requirement -- unless you are specifically meaning "a bump-in-the-wire deployment over a point to point link" users fairly much never have control over the path that the tunnel will take. At some point the primary path **will** go down, and the tunnel will route over some backup path, most likely at 3AM on the Sunday that the CEO's daughter is getting married... It what you are describing really is "only ever use this as a bump-in-the-wire over a PtP interface" or "make sure that the configured bandwidth is many many magnitudes smaller than the smallest link in the network, even when congested", then please state that instead. As written, this text seems dangerous: you are basically handing an enterprise network admin a DoS cannon and washing your hands of the consequences. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Much thanks to Bo Wu for the OpsDir review, and to the authors for addressing / incorporating the comments. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
