[Gen-art] draft-ietf-idr-sr-policy-nrp-11 ietf last call Genart review

[Mallory Knodel via Datatracker <[e-mail]>]

Document: draft-ietf-idr-sr-policy-nrp
Title: BGP SR Policy Extensions for Network Resource Partition
Reviewer: Mallory Knodel
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-idr-sr-policy-nrp-??
Reviewer: Mallory Knodel
Review Date: 2026-06-16
IETF LC End Date: 2026-06-15
IESG Telechat date: 2026-07-02

Summary: I am not a domain expert and am reviewing for readability and
comprehension. The document is clear, complete, architecturally aligned for
someone outside IDR, so thanks for writing it. It extends BGP segment routing
policy signaling so that a path can be explicitly associated with a specific
Network Resource Partition (NRP).

Major issues: None.

Minor issues:

 * It seems that there is a missing architectural overview of this
 specification that could be elaborated in the introduction. For example, there
 is no mention of "inter-domain" anywhere in the document. It leaves a
 non-expert like me wondering what this looks like across various domains or
 ASes. Perhaps such a paragraph could also contain an example of inter-domain
 coordination.

 * Under the procedures section validity is mentioned, "...a BGP speaker
 determines if it is valid and usable according to ... RFC9830," but there is
 no direct mention of an "invalid" or "unusable" NRP ID sub-TLV. Perhaps this
 is what is meant in the second paragraph of the section on Error Handling, but
 then the language could be harmonized.

 * The first paragraph should summarize the security considerations cited, not
 just giving the citation. The second paragraph in security considerations
 points to an I-D, not an RFC so I would suggest bringing those relevant
 sections' full text into this document if it is published first.

Nits/editorial comments:

 * Second paragraph in the introduction has some clumsy wording, "... NRP-based
 enhanced VPN services based on VPN..."

 * Right after that "Traffic Engineering (TE)" defines the acronym "TE" but it
 is never used again so suggesting dropping this.

 * The acronyms "SAFI" and "NLRI" are never expanded.

 * Make consistent the use of singular/plural "NRP/NRPs".

 *