Éric Vyncke has entered the following ballot position for draft-ietf-bess-bgp-sdwan-usage-32: 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-bess-bgp-sdwan-usage/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke INT AD comments for draft-ietf-bess-bgp-sdwan-usage-31 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). I hope that this review helps to improve the document, Regards, -éric Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## COMMENTS (non-blocking) ### Wrong copyright s/Simplified/Revised/ ### Deviation from the goal I second Med Boucadair's `The document deviates from the goal set ` but not at the DISCUSS level. ### PCE not mentioned I am surprised to see mention of the PCE WG published RFC in the document, e.g., in section 4. ### Section 1 Shouldn't the MEF reference for SD-WAN be normative ? Please expand NSP at first use. ``` Publishing this material as an RFC provides a stable, citable foundation for related protocol specifications and ensures a shared understanding of the problem space across the industry. ``` has probably little benefit in the published RFC. ### Section 3.1.1 While VxLAN is the de facto standard, it is informational, why not adding GENEVE in the text ? ### Section 3.1.4 I would not qualify ZTP the requirement to insert a USB stick ;-) ### Section 3.2 Please add reference for NVo3 on figure 3. ### Section 3.3 s/Since IPsec encryption requires significant processing power/Since IPsec encryption requires significant processing power *or dedicated processor*/ ### Section 4.3 `BGP UPDATE messages could be extended to propagate IPsec-related attributes ` does the absence of references mean that this not possible now ? I.e., no IETF RFC for this extension ? Same ambiguity in UPDATE2 of section 5.3. ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-) _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
