Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. 

The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/.

While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received.


- Document: draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13

- Reviewer: Ran Chen

- Review Date: Jan 13, 2026

- Intended Status: Standards Track

 
---

## Summary 
- Has Issues: I have some minor concerns about this document that I think should be resolved before publication.
This draft defines a method for assigning SRv6 Locators to SRv6 Segment Endpoint Nodes (such as CPEs) using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The document also describes the operational procedures for SRv6 Locator allocation, route advertisement through IGPs by BRAS (functioning as a DHCP relay or server), and the specific behaviors required for DHCP clients, servers, and relay agents.

## General Operational Comments Alignment with RFC 5706bis 
Although the draft does not have a dedicated section titled "Operational Considerations", its core content in Section 5 ("Operational Procedures”) already provides a detailed description of the operational workflows. To better align with IETF best practices and the guidelines set forth in RFC 5706bis, I recommend that the authors consider summarizing or restructuring the operational logic from Section 5 into a formal "Operational Considerations" section. This would enhance the document's clarity regarding deployment, management, and real-world operational impacts.
---

## Major Issues 
No major issues found. 

---

## Minor Issues 

Section 5.4 specifies that the server MUST return a NoSRv6LocatorAvail status code if it cannot assign an SRv6 locator. However, the draft remains underspecified regarding the expected client behavior upon receiving this error. Beyond simply retrying the request, should the document define a mechanism? 

Suggested text：
“The client uses the SRv6 locators and associated information from any IAs that do not contain a Status Code option with the NoSRv6LocatorAvail status code. The client MAY include IAs that received a NoSRv6LocatorAvail status code, without any SRv6 Locators, in subsequent Renew or Rebind messages to retry obtaining the SRv6 Locators for those IAs.”

---

## Nits 
-The document uses "CPE" and "DHCP client" interchangeably in section 5; it is recommended to clarify the relationship between them， Alternatively, use client (CPE) instead of CPE in section 5. 
-Terminology Consistency: Please perform a global search and replace to ensure all instances of "segment IDs" are updated to "segment identifiers". This change ensures strict alignment with RFC8402.
-In the first occurrence within the main body of the text, please provide the full name for the protocol: Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
-s/ BRAS (Broadband Remote Access Server)/ Broadband Remote Access Server(BRAS)
---