Éric Vyncke has entered the following ballot position for draft-ietf-bess-bgp-srv6-args-08: 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-srv6-args/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-bess-bgp-srv6-args-08 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit. Special thanks to Zhaohui (Jeffrey) Zhang for the shepherd's 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 ## COMMENTS (non-blocking) ### Abstract Suggest removing the first sentence. Possibly add a reference to RFC 8986 network programming as this is specific to net-pgm and not plain SRv6. ### Section 1 s/SRv6 refers to Segment Routing instantiated on the IPv6 data plane/SRv6 refers to Segment Routing instantiated *over* the IPv6 data plane/ ? *VERY* ambiguous statement `SRv6 Service Segment Identifier (SID) refers to an SRv6 SID` (recursive and conflicting redefinition of SID) ### Section 2 `As specified in [RFC8986], an SRv6 SID comprises three components:` is not correct as RFC 8402 that defines SID has not this structure. So, let's be specific and states that "RFC 8946 SID comprises three components" or something similar. ### Section 3.1 s/Ethernet Auto-Discovery (A-D) ... are utilized/s/Ethernet Auto-Discovery (A-D) ... *is* utilized/ ? `::0` is not a canonical format for "::". s/0:0:0:0:aaaa::/::aaaa:0:0:0/ (also in section 3.3) ### Section 3.3 `BUM` is already define before. ### Being more generic ? Sections 3.1 and 3.2 seems very specific, but should the described mechanism be more generic ? The bit-wise OR seems indeed too simplistic and this mechanism could be used for other end point behavior beyond those described in section 3.1 and 3.2 ## NITS (non-blocking / cosmetic) ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-) _______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
