I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

The subject is outside my area of expertise and I did not spot any
security related areas of concern, but I did have feedback that affected
my ability to understand the content.

https://1drv.ms/b/c/dc2b364f3f06fea8/IQDO-Y3nJmFgSpp_RnbWQ1fZATcHg2mmFtU2AHBy0130ToU?e=6QKzkc
has a PDF with comments inline.  There are many editorial nits,
mainly grammatical issues that I provide suggested fixes for in the
marked up PDF and won't mention in this email.

Some less trivial issues include:

1. Page 5 says:
   > As the information is sourced from OSPF or IS-IS, the
   > value MUST correspond to one of IGP values as specified
   > in [RFC9552].

   Table 2 in RFC 9552 also contains values for Direct and Static
   configuration.  Does “As the information is sourced from OSPF
   or IS-IS” mean the Direct and Static values MUST NOT be used
   here?  Clarify.

2. Figure 2 shows a 64-bit "Identifier" field, and it says:
   > The semantics of "Identifier" field are the same as defined in
   > [RFC9552] and will be set to a value that is identical to the
   > "Identifier" value of the IGP domain associated with the ASBR of the
   > inter-AS link.  Therefore, the "Identifier" values for the two half-
   > links (refer section 5.2.2 of [RFC9552]) of the inter-AS link could
   > be different depending on the configuration of Identifiers for the
   > two IGP domains.

   I’m having trouble matching up a 64-bit identifier as used here with
   something in 5.2.2 of RFC9552.  That section appears to talk about
   multi-topology identifiers (section 5.2.2.1, longer than 64 bits) and
   link-local/remote identifiers (RFC 5307 section 1.1) which do appear
   to be 64-bits.  If you specifically mean link-local/remote identifiers
   instead of multi-topology identifiers, then specifically say so and
   perhaps reference RFC 5307 section 1.1 instead.   Otherwise, please
   explain.

3. Several places talk about there being "no place in the current
   BGP-LS protocol"...  I’d recommend avoid using the word “current”
   anywhere in this document, since once published and presumably
   deployed, this word won’t be true by the time other readers
   read this document.  “at the time of this writing” would be
   more accurate.  Or you could just say it’s not in RFC 9552.

4. "BGP Peering Engineering" is capitalized but not defined.  Should it be?
   Or maybe uncapitalize it?

5. "Internet Data Centers" is used as a term rather than simply
   "Data Centers".  It's not clear to me what the difference is,
   especially since the document talks about "walled gardens".

Dave