Advertisement of Segment Routing Policies using BGP Link-State
draft-ietf-idr-bgp-ls-sr-policy-17

Thank you to Ned Smith for their secdir review

Section 7, paragraph 0
>    The Existing BGP operational and management procedures apply to this
>    document.  No new procedures are defined in this document.  The
>    considerations as specified in [RFC9552] apply to this document.

Thanks to Susan Harris for the Shepherd review and to Tina Tsou for the OPSDIR review. Susan in her writeup highlights some of the operational considerations that come from the OPSDIR review. I would agree that some of those considerations should be taken up by the SRv6ops WG as possible work items, instead of trying to address them in this document. The chairs of SRv6ops have been looped into that discussion. At this time, I do not feel additional updates are needed in this document.

Check whether Expert Review is an appropriate registration policy here.

No reference entries found for these items, which were mentioned in the text:
[draft-ietf-pce-segment-routing-policy-cp].

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Terms "his" and "her"; alternatives might be "they", "them", "their"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 15
>    This extensions specified in this document complement the BGP SR
>    Policy SAFI [I-D.ietf-idr-sr-policy-safi] and
>    [I-D.ietf-idr-bgp-sr-segtypes-ext] that are used to advertise SR
>    Policies from controllers to the headend routers using BGP by
>    enabling the reporting of the operational state of those SR Policies
>    back from the headend to the controllers.

s/This extensions specified/The extensions specified/

These URLs in the document did not return content:

 * https://ieeexplore.ieee.org/document/8766220

Section 1, paragraph 9
> Policy headend nodes) via PCEP NIT: This extensions specified in this documen
>                                     ^^^^
The singular determiner "this" may not agree with the plural noun "extensions".
Did you mean "these"?

Section 1, paragraph 11
> m the headend to the controllers. s/This extensions specified/The extensions
>                                     ^^^^
The singular determiner "this" may not agree with the plural noun "extensions".
Did you mean "these"?

Section 5.6.1, paragraph 3
>  their paths. The types disjointness are described in section 3 of [RFC8800] 
>                                      ^^^
The verb form "are" does not seem to match the subject "disjointness".

Section 5.6.2, paragraph 2
> ndicates that the computation may fallback to a lower level of disjointness 
>                                   ^^^^^^^^
The word "fallback" is a noun. The verb is spelled with a space.

Section 5.6.2, paragraph 3
> ndicates that the computation may fallback to the default best path (e.g. IG
>                                   ^^^^^^^^
The word "fallback" is a noun. The verb is spelled with a space.

Section 5.6.6, paragraph 8
> -Flag: Indicates the SID-List is comprised of SRv6 SIDs when set and indicate
>                               ^^^^^^^^^^^^^^^
Did you mean "comprises" or "consists of" or "is composed of"?

Section 5.6.6, paragraph 8
>  SIDs when set and indicates it is comprised of SR/MPLS labels when clear. - 
>                                 ^^^^^^^^^^^^^^^
Did you mean "comprises" or "consists of" or "is composed of"?

Section 8.3, paragraph 3
> d/or controllers/applications in a secure manner within this trusted SR domai
>                               ^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "securely" to avoid wordiness.

Thank you Meral Shirazipour for the GENART review.

I have my usual gripe in Section 5.1 about use of SHOULD [NOT] without any guidance about how to decide when it might be reasonable to deviate from the advice given.  Can we provide some?

Thanks for working on this specification. 

I have one comment, I think it would improve the understanding of the ask if addressed. 

# Section 5.6.3 and 5.7.3 mention -

     If multiple instances are present, then the first valid one is used
   and the rest are ignored.

  How is that validity check done? A reference to the validity check procedure would be helpful here.