Tim, Med (as AD),

** Med, please review and let us know if you approve the following sentence, 
which Tim added to LPD-5. (This addition is also shown in the diff files below.)

            Packets with destination
            addresses in a delegated prefix MUST be routed to that
            prefix regardless of which interface they are received on.

In context, it is:

   LPD-5:   IPv6 CE routers MUST maintain a local routing table that is
            dynamically updated with leases and the associated next hops
            as they are delegated to clients.  Packets with destination
            addresses in a delegated prefix MUST be routed to that
            prefix regardless of which interface they are received on.
            When a delegated prefix is released or expires, the
            associated route MUST be removed from the IPv6 CE router's
            routing table.  A delegated prefix expires when the valid
            lifetime assigned in the IA_PD expires without being
            renewed.  When a prefix is released or expires, it MUST be
            returned the pool of available prefixes.

Tim,
Thank you for your reply and the updated XML file. One note is below. The 
revised files are here (please refresh):
  https://www.rfc-editor.org/authors/rfc9818.html
  https://www.rfc-editor.org/authors/rfc9818.txt
  https://www.rfc-editor.org/authors/rfc9818.pdf
  https://www.rfc-editor.org/authors/rfc9818.xml

This diff file shows all changes from the approved I-D:
  https://www.rfc-editor.org/authors/rfc9818-diff.html
  https://www.rfc-editor.org/authors/rfc9818-rfcdiff.html (side by side)

This diff file shows the changes made during AUTH48 thus far:
  https://www.rfc-editor.org/authors/rfc9818-auth48diff.html
  https://www.rfc-editor.org/authors/rfc9818-auth48rfcdiff.html (side by side)

We will wait to hear from you again and from your coauthors
before continuing the publication process. This page shows 
the AUTH48 status of your document:
  https://www.rfc-editor.org/auth48/rfc9818

FYI, in Section 1, added 's' as shown below; please let us know if that is not 
the intended meaning.

OLD: The default configuration of CE router is designed to be a
     flat model to support zero-configuration networking.

NEW: The default configuration of CE routers is designed to be a
     flat model to support zero-configuration networking.


I'm here at IETF 123 at the RFC Editor desk (near registration) if you want to 
come by and say hello. Will also be here Wed. afternoon and Thur. morning.

Thank you.
RFC Editor/ar

> On Jul 22, 2025, at 10:51 AM, Timothy Winters <t...@qacafe.com> wrote:
> 
> Hi Alice,
> 
> Here is the updated xml file, I responded to all the questions in the xml.  
> Let me know if there are unresolved issues.
> 
> ~Tim
> 
> 
> 
> 
> On Mon, Jul 21, 2025 at 4:15 PM Timothy Winters <t...@qacafe.com> wrote:
> Hi Alice,
> 
> Thanks I have started reviewing the changes and will have an update this week.
> 
> ~Tim
> 
> On Mon, Jul 21, 2025 at 3:16 PM Alice Russo <aru...@staff.rfc-editor.org> 
> wrote:
> Tim,
> 
> This is a reminder that we await word from you regarding the questions below 
> and this document's readiness for publication as an RFC. The files are here:
> 
>  https://www.rfc-editor.org/authors/rfc9818.html
>  https://www.rfc-editor.org/authors/rfc9818.pdf
>  https://www.rfc-editor.org/authors/rfc9818.txt
>  https://www.rfc-editor.org/authors/rfc9818.xml (source)
> 
> Diff files of all changes from the approved Internet-Draft:
>  https://www.rfc-editor.org/authors/rfc9818-diff.html 
>  https://www.rfc-editor.org/authors/rfc9818-rfcdiff.html (side by side)
> 
> This page shows the AUTH48 status of your document:
>  https://www.rfc-editor.org/auth48/rfc9818
> 
> Thank you.
> RFC Editor/ar
> 
> > On Jul 3, 2025, at 5:51 PM, rfc-edi...@rfc-editor.org wrote:
> > 
> > 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, at 6:01 PM, rfc-edi...@rfc-editor.org wrote:
> > 
> > Tim,
> > 
> > One additional question:
> > 
> > 12) Re: LPD-6, what does "that is not assigned" refer to? As far as verb 
> > agreement, it does not match "packets". 
> > 
> > Original:
> > IPv6 CE routers MUST continue to drop packets
> > including destination address that is not assigned to the
> > LAN or delegated.
> > 
> > Perhaps:
> > IPv6 CE routers MUST continue to drop packets,
> > including destination address, that are not assigned to the
> > LAN or delegated.
> > 
> > Thank you.
> > RFC Editor/ar
> 
> 
> 
> <rfc9818.xml>

-- 
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org

Reply via email to