[auth48] Re: Final Review: RFC-to-be 10038 (draft-ietf-spring-dhc-distribute-srv6-locator-dhcp) in XML

[Dan Voyer <[e-mail]>]

Hi Alanna, all,

I have reviewed the final changes and approve RFC-to-be 10038 for publication.

Thank you,
Dan


From: [e-mail] <[e-mail]>
Date: Tuesday, August 25, 2026 at 5:41 AM
To: Alanna Paloma <[e-mail]>; linchangwang.04414 <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; danvoyerwork <[e-mail]>; [e-mail] <[e-mail]>; hanruibo <[e-mail]>; davoyer <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; gunter.van_de_velde <[e-mail]>; james.n.guichard <[e-mail]>; ketant.ietf <[e-mail]>; buraglio <[e-mail]>; spring-chairs <[e-mail]>
Subject: Re: Re: Final Review: RFC-to-be 10038 (draft-ietf-spring-dhc-distribute-srv6-locator-dhcp) in XML

Hi All,

I am pleased to approve the publication of the draft.

Thank you all for your efforts.

Best regards,
Weiqiang Cheng

From: Alanna Paloma<mailto:[e-mail]>
Date: 2026-08-22 01:28
To: linchangwang<mailto:[e-mail]>
CC: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Final Review: RFC-to-be 10038 (draft-ietf-spring-dhc-distribute-srv6-locator-dhcp) in XML
Hi Changwang,

Thank you for your reply.  We have updated as requested.

The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc10038.xml
https://www.rfc-editor.org/authors/rfc10038.txt
https://www.rfc-editor.org/authors/rfc10038.html
https://www.rfc-editor.org/authors/rfc10038.pdf

The relevant diff files have been posted here:
https://www.rfc-editor.org/authors/rfc10038-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc10038-auth48diff.html (Final Review changes)
https://www.rfc-editor.org/authors/rfc10038-auth48rfcdiff.html (Final Review changes side by side)

Please review the document carefully and contact us with any further updates you may have.  Note that we do not make changes once a document is published as an RFC.

We will await approvals from each party listed on the Final Review status page below prior to moving this document forward in the publication process.

For the Final Review status of this document, please see:
https://queue.rfc-editor.org/final-review/rfc10038/

Thank you,
Alanna Paloma
RFC Production Center


> On Aug 20, 2026, at 11:48 PM, linchangwang <[e-mail]> wrote:
>
>
> Hi,
>
> Thank you for your valuable feedback.
> For a detailed response, please see the reply below.
>
> Thanks,
> Changwang
>
>
> 发件人: [e-mail] <[e-mail]>
> 发送时间: 2026年8月21日 10:27
> 收件人: [e-mail]; [e-mail]; linchangwang (RD) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> 抄送: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> 主题: Re: Final Review: RFC-to-be 10038 (draft-ietf-spring-dhc-distribute-srv6-locator-dhcp) in XML
>
>
> Authors,
>
> While reviewing this document during Final Review, please resolve (as necessary) the following questions, which are also in the source file.
>
>
> 1) <!--[rfced] Document title
>
> a) We have expanded the abbreviation SRv6 in the document title per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review.
>
> 【Changwang]  I agree with the above modifications.
>
> b) Are any further updates to the document title needed per the following questions? Note that if any changes are made to the document title, similar updates may be needed for the abbreviated title (only appears in the running header at the top of each page in the PDF output).
>
> - Should "Distribute" be updated to "Distributing"?
> - "DHCP" is used in the document title, but "DHCPv6" is used in the abstract. Is
>  is this okay, or are updates needed?
> - Is "by" the correct preposition?
>
> Original:
>   Distribute SRv6 Locator by DHCP
>
> Current:
>   Distribute Segment Routing over IPv6 (SRv6) Locator by DHCP
>
> Perhaps:
>   Distributing the Segment Routing over IPv6 (SRv6) Locator Using DHCPv6
> -->
>
> 【Changwang] Distributing the Segment Routing over IPv6 (SRv6) Locator Using DHCPv6
>
>
> 2) <!--[rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. -->
>
> 【Changwang]  SRv6 Locator , IA_SRV6_LOCATOR,  OPTION_IA_SRV6_LOCATOR, OPTION_IALOCATOR,  IA Locator, IA_PD,  NoSRv6LocatorAvail, BRAS, CPE
>
> 3) <!--[rfced] Should "Rebind" be added to the list in this sentence based on the text in Section 5.1?
>
> Original:
>   The IA_SRV6_LOCATOR option can be carried in DHCPv6 Solicit,
>   Advertise, Request, Reply, Renew, and Release messages.
>
> Perhaps:
>   The IA_SRV6_LOCATOR option can be carried in DHCPv6 Solicit,
>   Advertise, Request, Reply, Renew, Release, and Rebind messages.
>
> Sentence in Section 5.1 that mentions Rebind message:
>   As described in Sections 18.2.5 of [RFC9915], if the client does not
>   receive a Reply message before the T2 timer expires, it sends a
>   Rebind message with the IA_SRV6_LOCATOR option to attempt lease
>   renewal.
> -->
>
> 【Changwang] The IA_SRV6_LOCATOR option can be carried in DHCPv6 Solicit,
>   Advertise, Request, Reply, Renew, Release, and Rebind messages.
>
>
>
> 4) <!-- [rfced] We do not see RFC 9350 listed as a reference for the "IGP Algorithm Types" registry at https://www.iana.org/assignments/igp-parameters#igp-algorithm-types.
> However, RFC 9350 does mention the "IGP Algorithm Types" registry.
> Are any updates needed to this sentence?
>
> Original:
>   Algorithm values are defined in the "IGP Algorithm
>   Types" registry [RFC8665] and [RFC9350].
>
> Perhaps:
>   Algorithm values are defined in the "IGP Algorithm
>   Types" registry [RFC8665].
>
> Or:
>   Algorithm values are defined in the "IGP Algorithm
>   Types" registry [RFC8665]. See also [RFC9350].
> -->
>
> [Changwang] Algorithm values are defined in the "IGP Algorithm
>   Types" registry [RFC8665]. See also [RFC9350].
>
>
>
> 5) <!--[rfced] We made some capitalization updates within Figure 4. Please review and let us know any concerns.
> -->
> 【Changwang]  I agree with the above modifications.
>
> 6) <!-- [rfced] Would you like to use field names here? Or is the current okay?
>
> Original:
>   The IA_SRV6_LOCATOR option
>   populates the SRv6 Locator block length, locator node length,
>   function length, and arguments length.
>
> Perhaps:
>   The IA_SRV6_LOCATOR option
>   populates the LB-Len, LN-Len, Fun-Len, and Arg-Len fields.
> -->
>
> 【Changwang]  The IA_SRV6_LOCATOR option
>   populates the LB-Len, LN-Len, Fun-Len, and Arg-Len fields.
>
>
> 7) <!--[rfced] Should "Routing Stability as an Additional Operational Consideration" be recast as a complete sentence (Perhaps A) or updated to be a subsection under the "Operational Considerations" section (Perhaps B)?
>
> Original:
>   Routing Stability as an Additional Operational Consideration.
>   Network operators may advertise an aggregated route rather than
>   individual prefixes in certain deployments to optimize Routing
>   Information Base (RIB) performance. ...
>
> Perhaps A (sentence):
>   Routing Stability is an additional operational consideration.
>   Network operators may advertise an aggregated route rather than
>   individual prefixes in certain deployments to optimize Routing
>   Information Base (RIB) performance. ...
>
> Perhaps B (subsection):
> 6.1.  Routing Stability as an Additional Operational Consideration
>
>   Network operators may advertise an aggregated route rather than
>   individual prefixes in certain deployments to optimize Routing
>   Information Base (RIB) performance. ...
> -->
>
> 【Changwang]  Choose A.
>   Routing Stability is an additional operational consideration.
>   Network operators may advertise an aggregated route rather than
>   individual prefixes in certain deployments to optimize Routing
>   Information Base (RIB) performance. ...
>
>
> 8) <!-- [rfced] Will readers understand what "them" refers to here?
>
> Original:
>   In some network environments, it is possible to secure them, as
>   discussed later in Section 22 of [RFC9915].
> --> 【Changwang] ”them" refers to "the communication between clients and servers."
> Please check whether it needs revision.
> If so, my suggestion would be to change it to: "secure the communication between clients and servers" or "secure these interactions."
>
> 9) <!-- [rfced] Abbreviations
>
> a) FYI - We have added an expansion for the following abbreviation per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness.
>
> Network Configuration Protocol (NETCONF)
>
> [Changwang] Agreed.
>
>
> b) Both the expansion and the acronym for the following terms are used throughout the document. Would you like to update to using the expansion upon first usage and the acronym for the rest of the document for consistency?
>
> Prefix Delegation (PD)
> Segment Routing (SR)
>
> --> [Changwang] Agreed.
>
>
> 10) <!-- [rfced] Terminology
>
> a) Throughout the text, the following terminology appears to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent.
>
> Client vs. client
>
> [Changwang] The description in the figure still uses "Client," while the text portion can be changed to "client."
>
> Server vs. server
>
> [Changwang] The description in the figure still uses " Server," while the text portion can be changed to " server."
>
> IA_SRV6_LOCATOR vs. IA_SRv6_LOCATOR ("V" vs. "v")
>   Note: The form with "V" (uppercase) appears in the IANA registry. If
>   we update to use the form with "v" (lowercase), we will request that
>   IANA update the registry as well.
>
> [Changwang] IA_SRV6_LOCATOR.
>
> Prefix Delegation vs. prefix delegation
>
> [Changwang] prefix delegation.
>
>
> b) May we update all instances of "SRv6 locator" to "SRv6 Locator" for consistency with the rest of the document?
>
> [Changwang] Agreed, please make the changes uniformly.
>
> c) We see both "DHCP" and "DHCPv6" used in the document. Please review and let us know if any updates are needed.
> -->
> [Changwang] Please uniformly change "DHCP client" to "DHCPv6 client", and leave the rest unchanged.
>
>
> 11) <!--[rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> and let us know if any changes are needed.  Updates of this nature typically result in more precise language, which is helpful for readers.
>
> In addition, please consider whether "traditional" should be updated for clarity.
> While the NIST website
> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
> indicates that this term is potentially biased, it is also ambiguous.
> "Tradition" is a subjective term, as it is not the same for everyone.
> -->
> [Changwang] Reviewed, no modifications needed.
>
>
> Thank you.
>
> Alanna Paloma and Rebecca VanRheenen
> RFC Production Center
>
>
>
> On Aug 20, 2026, at 7:23 PM, [e-mail] wrote:
>
> *****IMPORTANT*****
>
> RFC Author(s):
> --------------
>
> Final Review for RFC-to-be 10038 <draft-ietf-spring-dhc-distribute-srv6-locator-dhcp>
>
> Your document is now available for Final Review (previously AUTH48). Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies; see the Unavailable Authors section (https://authors.ietf.org/rfc-publication-process#unavailable-authors)
>
> You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval.
>
> Planning your review
> ---------------------
>
> Please review the following aspects of your document:
>
> *  RFC Editor questions
>
>  Please review and resolve any questions raised by the RFC Editor
>  that have been included in the XML file as comments marked as
>  follows:
>
>  <!-- [rfced] ... -->
>
>  These questions will also be sent in a subsequent email.
>
> *  Changes submitted by coauthors
>
>  Please ensure that you review any changes submitted by your
>  coauthors.  We assume that if you do not speak up that you
>  agree to changes submitted by your coauthors.
>
> *  Content
>
>  Please review the full content of the document, as this cannot
>  change once the RFC is published.  Please pay particular attention to:
>  - IANA considerations updates (if applicable)
>  - contact information
>  - references
>
> *  Copyright notices and legends
>
>  Please review the copyright notice and legends as defined in
>  RFC 5378 and the Trust Legal Provisions
>  (TLP – https://trustee.ietf.org/license-info)
>
> *  Semantic markup
>
>  Please review the markup in the XML file to ensure that elements of
>  content are correctly tagged.  For example, ensure that <sourcecode>
>  and <artwork> are set correctly.  See details at
>  <https://authors.ietf.org/rfcxml-vocabulary>.
>
> *  Formatted output
>
>  Please review the PDF, HTML, and TXT files to ensure that the
>  formatted output, as generated from the markup in the XML file, is
>  reasonable.  Please note that the TXT will have formatting
>  limitations compared to the PDF and HTML.
>
>
> Submitting changes
> ------------------
>
> To submit changes, please reply to this email using 'REPLY ALL' as all the parties CCed on this message need to see your changes. The parties
> include:
>
>  *  your coauthors
>
>  *  [e-mail] (the RPC team)
>
>  *  other document participants, depending on the stream (e.g.,
>     IETF Stream participants are your working group chairs, the
>     responsible ADs, and the document shepherd).
>
>  *  [e-mail], which is an archival mailing list
>     to preserve discussion about the document while in the RPC editorial
>     queue; it is not an active discussion list:
>
>    *  More info:
>       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>
>    *  The archive itself:
>       https://mailarchive.ietf.org/arch/browse/auth48archive/
>
>    *  Note: If only absolutely necessary, you may temporarily opt out
>       of the archiving of messages (e.g., to discuss a sensitive matter).
>       If needed, please add a note at the top of the message that you
>       have dropped the address. When the discussion is concluded,
>       [e-mail] will be re-added to the CC list and
>       its addition will be noted at the top of the message.
>
> You may submit your changes in one of two ways:
>
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
>
> Section # (or indicate Global)
>
> OLD:
> old text
>
> NEW:
> new text
>
> You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient.
>
> We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes.  Information about stream managers can be found in the FAQ.  Editorial changes do not require approval from a stream manager.
>
>
> Approving for publication
> --------------------------
>
> To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication.  Please use 'REPLY ALL', as all the parties CCed on this message need to see your approval.
>
>
> Files
> -----
>
> The files are available here:
>  https://www.rfc-editor.org/authors/rfc10038.xml
>  https://www.rfc-editor.org/authors/rfc10038.html
>  https://www.rfc-editor.org/authors/rfc10038.pdf
>  https://www.rfc-editor.org/authors/rfc10038.txt
>
> Diff file of the text:
>  https://www.rfc-editor.org/authors/rfc10038-diff.html
>  https://www.rfc-editor.org/authors/rfc10038-rfcdiff.html (side by side)
>
> Alt-diff of the text (allows you to more easily view changes where text has been deleted or moved):
>  https://www.rfc-editor.org/authors/rfc10038-alt-diff.html
>
> Diff of the XML:
>  https://www.rfc-editor.org/authors/rfc10038-xmldiff1.html
>
>
> Tracking progress
> -----------------
>
> Details on the status of your Final Review are here:
>  https://queue.rfc-editor.org/final-review/rfc10038/
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC 10038 (draft-ietf-spring-dhc-distribute-srv6-locator-dhcp)
>
> Title            : Distribute SRv6 Locator by DHCP
> Author(s)        : W. Cheng, Ed.,
>                  R. Han,
>                  C. Lin, Ed.,
>                  D. Voyer,
>                  G. Zhang
> WG Chair(s)      : Bruno Decraene, Alvaro Retana, Joel Halpern
> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde
> -------------------------------------------------------------------------------------------------------------------------------------
> 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组。
> 禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。
> 如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above.
> Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited.
> If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!