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 summary of the review is Ready with Issues.

A marked up PDF with my comments inline is at
https://1drv.ms/b/c/dc2b364f3f06fea8/IQBk314NW8yTRK5IpL47oH64AfLrq4sFanVMsmVgVPonVZs?e=fiaEu4

Technical issues:

1. The use of "SHOULD be set to zero" for Flags and Reserved means
   that those fields can never be used for anything in the future
   since a compliant implementation can set them to something other
   than zero now, in which case a receiver could not reliably
   distinguish the meaning.  Why SHOULD and not MUST, which would
   make them be usable in the future?

2. Section 3 (Procedures) leaves some behavior underspecified, or
   unspecified.  Specifically, the first paragraph uses two SHOULDs
   for what it should do, without saying what the alternative is:

   > When a candidate path of SR Policy is instantiated within an NRP, and
   > a network-wide data plane NRP Selector ID is used for identifying the
   > resources of the NRP, the originating node of SR Policy SHOULD
   > include the NRP sub-TLV in the BGP Tunnel Encapsulation Attribute of
   > the BGP SR Policy. The setting of other fields and attributes in BGP
   > SR Policy SHOULD follow the mechanism as defined in [RFC9830].

   I believe this is both an interoperability issue (since an implementation
   could do arbitrary behavior and still claim compliance) and a potential
   security issue, as RFC 2119 explains "Document authors should take
   the time to elaborate the security implications of not following
   recommendations or requirements as most implementors will not have
   had the benefit of the experience and discussion that produced the
   specification."

3. Similarly the second paragraph of section 3 also uses a SHOULD in
   the second sentence without any limits on alternatives:

   > If the SR Policy
   > candidate path selected as the best candidate path is associated with
   > an NRP, the headend node of the SR Policy SHOULD map the NRP ID to
   > the data plane NRP Selector ID, then encapsulate both the NRP
   > Selector ID and the segment list of the selected candidate path in
   > the header of packets which are steered to the SR Policy.

4. The last sentence on page 5 says that the mechanisms "would [be]
   based on ... RFC 9789", where "based on" (not "defined in") sounds
   like they're not yet specified:

   > For SR Policy with MPLS data
   > plane, the mechanisms of mapping and encapsulation of the NRP
   > Selector ID in the packet would be based on the framework defined in
   > [RFC9789].

   If it's left for a future specification, say so, so it's clear
   that simply claiming conformance to the referenced documents will
   not be sufficient to claim interoperability or standardization.

5. Two references listed in the Informative References section appear
   to be used in apparently normative ways in the text.  They should
   either move to the Normative References section, or else the text
   should change. The references are [I-D.jiang-spring-sr-policy-nrp]
   and [I-D.ietf-6man-enhanced-vpn-vtn-id].

Editorial issues:

6. A bunch of grammatical nits which can be found in the marked-up PDF
   which I won't repeat in this message since I don't expect they
   should need any discussion.

Dave Thaler