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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Mallory,

Many thanks for your review. Please see replies inline with Jie>:

-----Original Message-----
From: Mallory Knodel via Datatracker <[e-mail]> 
Sent: Wednesday, June 17, 2026 8:40 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: draft-ietf-idr-sr-policy-nrp-11 ietf last call Genart review

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.

Jie> The architectural overview is provided in an accompanying document: draft- ietf-spring-sr-policy-nrp, which is referenced by this draft. 
Jie> Although BGP was initially designed for inter-domain routing, in the context of BGP based SR Policy signaling, it is mainly used within a single domain, or several domains which are under the same administration. Thus inter-domain coordination is considered out of the scope of this document.

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

Jie> You are right that the description of valid and usable is related to the validation of an SR Policy candidate path, while the error handling section is about the syntactic check of the NRP ID sub-TLV. They are arranged in different sections on purpose. 

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

Jie> Thanks for your suggestion, we will add summary of the security considerations in the cited documents. 


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

 *

Jie> Thanks, we will fix these nits in next revision..

Best regards,
Jie