Alvaro Retana has entered the following ballot position for draft-ietf-grow-bmp-local-rib-11: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-local-rib/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS! I still have some non-blocking comments which have not been addressed in the latest version. (1) §3 (Definitions) * Post-Policy Adj-RIB-Out: The result of applying outbound policy to an Adj-RIB-Out. This MUST be what is actually sent to the peer. s/This MUST be what is actually sent to the peer./This is what is sent to the peer. Note that this document should not use Normative language related to what a BGP session does. In this case, that is rfc4271's job. (2) §5.2.1: "The Information field contains a UTF-8 string..." Please take a look at the Shutdown Communication string definition in rfc9003 and use a similar definition. (3) §5.2.1: "...whose value MUST be equal to the value of the VRF or table name (e.g., RD instance name) being conveyed." The "value of the VRF or table name" is a local matter, right? How can the requirement be normatively enforced? How can the receiver enforce the "MUST"? IOW, s/MUST.../The information field contains the value of the VRF or table name... There's no need to redefine the TLV in §5.3. (4) §5.5 (Route Mirroring): "Route mirroring is not applicable to Loc-RIB and Route Mirroring messages SHOULD be ignored." If not applicable...when is it ok not to ignore the Route Mirroring messages? IOW, why is this behavior recommended and not required? (6) In general, the terminology used throughout the document is well-known to BMP/BGP users but may not be to the average reader. Please add references (most can be informational). These are some examples: - s/Adj-RIB-In Post-Policy/Post-Policy Adj-RIB-In/g That is how rfc7854 defines the term. Also, please add a reference on first mention. - s/Adj-RIB-In Pre-Policy/pre-policy Adj-RIB-In/g Same as above. - Add a reference for BGP-LS (rfc7752). - Add a reference for "4-octet ASN" (rfc6793). _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow