Hi Mallory, Many thanks for your review. Please see replies inline with Jie>:
-----Original Message----- From: Mallory Knodel via Datatracker <[email protected]> Sent: Wednesday, June 17, 2026 8:40 AM To: [email protected] Cc: [email protected]; [email protected]; [email protected] 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 _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
