Greetings,
While reviewing this document during AUTH48
(https://www.rfc-editor.org/authors/rfc9818.html and other formats), please
resolve the following questions, which are also in the XML file.
1) <!-- [rfced] How may this title be rephrased for clarity?
Also, is "LAN" needed in this title? (Neither "LAN" nor "local" is mentioned
in the abstract.) Do either of these options convey the intended meaning?
Please feel free to suggest otherwise.
Original:
IPv6 CE Routers LAN DHCPv6 Prefix Delegation
Current:
IPv6 Customer Edge (CE) Routers LAN DHCPv6 Prefix Delegation
Option A:
DHCPv6 Prefix Delegation on IPv6 Customer Edge (CE) Routers in LANs
Option B:
DHCPv6 Prefix Delegation in LANs for IPv6 Customer Edge (CE) Routers
-->
2) <!--[rfced] For clarity, how may this be rephrased? In particular,
the phrase "CE Router supporting prefix delegation" is unclear.
Original:
The default configuration of CE Router supporting
prefix delegation is designed to be a flat model to support zero
configuration networking.
Perhaps:
For prefix delegation that supports CE routers, the default
configuration is designed to be a flat model to support
zero-configuration networking.
Or simply:
For prefix delegation that supports CE routers, the default
configuration is a flat model to support zero-configuration
networking.
-->
3) <!--[rfced] Please clarify "multi-provisioned networks". Is there
another term that is more common? The term "multi-provisioned"
does not appear in past RFCs or current Internet-Drafts.
Original:
This document does not cover dealing with multi-provisioned networks
with more than one provider.
-->
4) <!--[rfced] Which update do you prefer, as this definition is missing 'the',
but perhaps you prefer to match the cited document?
Original: IPv6 node: A device that implements IPv6 protocol.
Option A: IPv6 node: A device that implements IPv6.
(to match RFC 8200, which is cited in the lead-in text)
Option B: IPv6 node: A device that implements the IPv6 protocol.
-->
5) <!-- [rfced] FYI, for expanding GUA, "Unique" has been changed to
"Unicast" in order to match RFC 4291. Please review.
Original:
* GUA:Global Unique Addresses, as defined in [RFC4291].
Current:
GUA: Global Unicast Address, as defined in [RFC4291].
-->
6) <!--[rfced] Please clarify; how should this fragment be updated to
be a sentence?
Original:
The end-user network for IPv6 that is a stub network.
-->
7) <!--[rfced] Please review this update for accuracy; due to "its",
the subject ("IPv6 CE routers") has been changed to singular. It
currently reads that a single router could have more than one LAN interface.
Original:
LPD-1: IPv6 CE routers MUST support IPv6 prefix assignment
according to Section 13.3 of [RFC8415] (Identity Association
for Prefix Delegation (IA_PD) option) on its LAN
interface(s).
Current:
LPD-1: Each IPv6 CE router MUST support IPv6 prefix assignment
according to Section 13.3 of [RFC8415] (Identity Association
for Prefix Delegation (IA_PD) option) on its LAN
interface(s).
Alternatively (both plural):
LPD-1: IPv6 CE routers MUST support IPv6 prefix assignment
according to Section 13.3 of [RFC8415] (Identity Association
for Prefix Delegation (IA_PD) option) on their LAN
interfaces.
-->
8) <!--[rfced] Because the second sentence is singular, should the first
sentence be parallel?
Original:
LPD-2: IPv6 CE routers MUST assign a prefix from the delegated
prefix as specified by L-2 in Section 4.3 of [RFC7084]. If
insufficient prefixes are available the IPv6 CE Router MUST
log a system management error.
Perhaps:
LPD-2: Each IPv6 CE router MUST assign a prefix from the delegated
prefix as specified by L-2 in Section 4.3 of [RFC7084]. If
insufficient prefixes are available, the IPv6 CE router MUST
log a system management error.
-->
9) <!--[rfced] Should "both ULA and GUA" be both "ULAs and GUAs"? If so,
please review whether "the GUA" is accurate in the second phrase.
Original:
LPD-9: If an IPv6 CE router is provisioning both ULA and GUA via
prefix delegation, the GUA SHOULD appear first in the DHCPv6
packets.
Perhaps:
LPD-9: If an IPv6 CE router is provisioning both ULAs and GUAs via
prefix delegation, the GUA SHOULD appear first in the DHCPv6
packets.
Or (singular):
LPD-9: If an IPv6 CE router is provisioning both the ULA and the GUA via
prefix delegation, the GUA SHOULD appear first in the DHCPv6
packets.
-->
10) <!--[rfced] Terminology
a) This term appeared inconsistently and has been updated to the latter.
Please let us know if you prefer otherwise.
CE Router vs. CE router [based on usage in RFC 7084]
b) Capitalization of these terms is not consistent. Please let us
know your preference.
Prefix Delegation vs. prefix delegation
Delegated Prefix (in LPD-6) vs. delegated prefix (in LPD-2, LPD-5)
c) Please review usage of this term and let us know if any updates are needed.
We note RFC 8415 uses the hyphen for the "prefix-length" field.
prefix-length (3 instances) vs. prefix length (2 instances)
-->
11) <!-- [rfced] FYI, the original URL provided for [eRouter] is to the most
recent version of this CableLabs specification, Version I22, which was
published in May 2024, so we updated the reference as follows.
Original:
[eRouter] CableLabs, "IPv4 and IPv6 eRouter Specification Version
I21", February 2022,
<https://www.cablelabs.com/specifications/CM-SP-eRouter>.
Current:
[eRouter] CableLabs, "IPv4 and IPv6 eRouter Specification", Data-
Over-Cable Service Interface Specifications, Version I22,
May 2024,
<https://www.cablelabs.com/specifications/CM-SP-eRouter>.
Re: "in Section 8.5 of CableLabs IPv6 eRouter specification [eRouter]",
we note that Section 8.5 has the same title in I21 and I122.
However, if you prefer to reference Version I21, please let us know
(and in that case, we recommend this URL:
https://www.cablelabs.com/specifications/CM-SP-eRouter?v=I21).
-->
Thank you.
RFC Editor/ar
On Jul 3, 2025, rfc-edi...@rfc-editor.org wrote:
*****IMPORTANT*****
Updated 2025/07/03
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered 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
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
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
* rfc-edi...@rfc-editor.org (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).
* auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; 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,
auth48archive@rfc-editor.org 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/rfc9818.xml
https://www.rfc-editor.org/authors/rfc9818.html
https://www.rfc-editor.org/authors/rfc9818.pdf
https://www.rfc-editor.org/authors/rfc9818.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9818-diff.html
https://www.rfc-editor.org/authors/rfc9818-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9818-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9818
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9818 (draft-ietf-v6ops-cpe-lan-pd-09)
Title : IPv6 CE Routers LAN DHCPv6 Prefix Delegation
Author(s) : T. Winters
WG Chair(s) : Ron Bonica, XiPeng Xiao, Nick Buraglio
Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
