Hi Ran,
Thank you very much for your thorough OpsDir review of
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13 and for providing
valuable comments. We agree with all of your suggestions and plan to
incorporate the corresponding changes in the next version of the draft.
Our point-by-point response is provided below inline.
B..R
Weiqiang
From: Ran Chen via Datatracker
Date: 2026-01-15 17:40
To: [email protected]
CC: draft-ietf-spring-dhc-distribute-srv6-locator-dhcp.all; last-call; spring
Subject: [spring] draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13 ietf
last call Opsdir review
Document: draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
Title: Distribute SRv6 Locator by DHCP
Reviewer: Ran Chen
Review result: Has Issues
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.
[Weiqiang] We will carefully address all the points you raised.
## 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.
[Weiqiang] We agree that this will better align the document with the RFC
5706bis guidelines, and we will revise the document structure accordingly.
---
## 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.”
[Weiqiang] You correctly pointed out that the draft currently under‑specifies
the expected client behavior after receiving a NoSRv6LocatorAvail error. The
text you proposed is clear and necessary. We accept this suggested text and
will add it to the relevant section of the document.
---
## 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.
[Weiqiang] We will clarify the relationship between the two in Section 5, and
consistently use “client (CPE)”.
-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.
[Weiqiang] Thank you for the reminder. We will perform a global
search‑and‑replace to ensure strict alignment with RFC 8402.
-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).
[Weiqiang] We will update it.
-s/ BRAS (Broadband Remote Access Server)/ Broadband Remote Access
Server(BRAS)
[Weiqiang] We will update it.
---
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
