[GROW] Alvaro Retana's No Objection on draft-ietf-grow-bmp-local-rib-11: (with COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

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).