[auth48] [IANA #1352759] [IANA] AUTH48: RFC-to-be 9527 <draft-ietf-homenet-naming-architecture-dhc-options-24> for your review

[David Dong via RT <[e-mail]>]

Hi Karen,

This change is complete; please see:

https://www.iana.org/assignments/dhcpv6-parameters/

Best regards,

David Dong
IANA Services Sr. Specialist

On Mon Jan 22 21:47:18 2024, [e-mail] wrote:
> Dear IANA,
> 
> Please update the "Supported Transport” registry at
> https://www.iana.org/assignments/dhcpv6-parameters as follows.
> 
> In the header of the first column in the table:
> 
> Old:
>    Bit Position (L to R)
> 
> New:
>    Bit Position (least to most significant)
> 
> Thank you in advance!
> RFC Editor/kc
> 
> 
> > On Jan 18, 2024, at 12:08 PM, Karen Moore <[e-mail]> wrote:
> >
> > Dear Éric,
> >
> > Thank you for your reply.  We have noted your approval on the AUTH48
> > status page for this document (https://www.rfc-
> > editor.org/auth48/rfc9527).
> >
> > We now have all necessary approvals and will move this document
> > forward in the publication process (along with RFC-to-be 9526 when
> > approved).
> >
> > Authors, thank you for your time!
> >
> > Best regards,
> > RFC Editor/kc
> >
> >
> >> On Jan 18, 2024, at 5:33 AM, Eric Vyncke (evyncke)
> >> <[e-mail]> wrote:
> >>
> >> Karen and authors,
> >>
> >> The change in section 4.4 (and in section 6.2) is approved.
> >>
> >> Regards
> >>
> >> -éric
> >>
> >> On 12/01/2024, 21:48, "Karen Moore" <[e-mail]
> >> <mailto:[e-mail]>> wrote:
> >>
> >>
> >> Hi Tomek and Éric (AD)*,
> >>
> >>
> >> Thanks for your quick reply; we have noted your approval on the
> >> AUTH48 status page for this document.
> >>
> >>
> >> *Éric, please review the addition of text in Section 4.4 and let us
> >> know if you approve. The update is included below and can also be
> >> viewed in this diff file: https://www.rfc-
> >> editor.org/authors/rfc9527-auth48diff.html <https://www.rfc-
> >> editor.org/authors/rfc9527-auth48diff.html>
> >>
> >>
> >> Section 4.4
> >> Current:
> >> As an example, the Supported Transport field expressing support for
> >> DomTLS looks as follows and has a numeric value of 0x0001:
> >>
> >>
> >> 0 1
> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | must be zero |1|
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>
> >>
> >> FILES (please refresh)
> >>
> >>
> >> The updated XML file is here:
> >> https://www.rfc-editor.org/authors/rfc9527.xml <https://www.rfc-
> >> editor.org/authors/rfc9527.xml>
> >>
> >>
> >> The updated output files are here:
> >> https://www.rfc-editor.org/authors/rfc9527.txt <https://www.rfc-
> >> editor.org/authors/rfc9527.txt>
> >> https://www.rfc-editor.org/authors/rfc9527.pdf <https://www.rfc-
> >> editor.org/authors/rfc9527.pdf>
> >> https://www.rfc-editor.org/authors/rfc9527.html <https://www.rfc-
> >> editor.org/authors/rfc9527.html>
> >>
> >>
> >> This diff file shows all changes made during AUTH48:
> >> https://www.rfc-editor.org/authors/rfc9527-auth48diff.html
> >> <https://www.rfc-editor.org/authors/rfc9527-auth48diff.html>
> >>
> >>
> >> This diff file shows only the changes made during the last editing
> >> round:
> >> https://www.rfc-editor.org/authors/rfc9527-lastrfcdiff.html
> >> <https://www.rfc-editor.org/authors/rfc9527-lastrfcdiff.html>
> >>
> >>
> >> This diff file shows all changes made to date:
> >> https://www.rfc-editor.org/authors/rfc9527-diff.html
> >> <https://www.rfc-editor.org/authors/rfc9527-diff.html>
> >>
> >>
> >> For the AUTH48 status of this document, please see:
> >> https://www.rfc-editor.org/auth48/rfc9527 <https://www.rfc-
> >> editor.org/auth48/rfc9527>
> >>
> >>
> >> Best regards,
> >> RFC Editor/kc
> >>
> >>
> >>> On Jan 12, 2024, at 12:06 PM, Tomek Mrugalski
> >>> <[e-mail] <mailto:[e-mail]>>
> >>> wrote:
> >>>
> >>> Hi Karen,
> >>>
> >>> I reviewed the updated text. It looks great!
> >>> I approve.
> >>>
> >>> Thanks!
> >>>
> >>> Tomek
> >>>
> >>> On 12.01.2024 21:02, Karen Moore wrote:
> >>>> Hi Tomek and Daniel,
> >>>> Thank you for your replies. We have updated our files accordingly.
> >>>> 1) Please review the bit rulers in Sections 4.2 and 4.3 to ensure
> >>>> that the number alignment is as expected.
> >>>> 2) Please review the placement of additional text in Section 4.4
> >>>> and let us know if any updates are needed. Note that we removed
> >>>> the hyphens from “must-be-zero” as it is not in attributive
> >>>> position (i.e., it is not followed by a noun).
> >>>> Once you confirm that everything is agreeable, we will ask the AD
> >>>> to approve the updates to Section 4.4.
> >>>> FILES (please refresh)
> >>>> The updated XML file is here:
> >>>> https://www.rfc-editor.org/authors/rfc9527.xml <https://www.rfc-
> >>>> editor.org/authors/rfc9527.xml>
> >>>> The updated output files are here:
> >>>> https://www.rfc-editor.org/authors/rfc9527.txt <https://www.rfc-
> >>>> editor.org/authors/rfc9527.txt>
> >>>> https://www.rfc-editor.org/authors/rfc9527.pdf <https://www.rfc-
> >>>> editor.org/authors/rfc9527.pdf>
> >>>> https://www.rfc-editor.org/authors/rfc9527.html <https://www.rfc-
> >>>> editor.org/authors/rfc9527.html>
> >>>> This diff file shows all changes made during AUTH48:
> >>>> https://www.rfc-editor.org/authors/rfc9527-auth48diff.html
> >>>> <https://www.rfc-editor.org/authors/rfc9527-auth48diff.html>
> >>>> This diff file shows only the changes made during the last editing
> >>>> round:
> >>>> https://www.rfc-editor.org/authors/rfc9527-lastrfcdiff.html
> >>>> <https://www.rfc-editor.org/authors/rfc9527-lastrfcdiff.html>
> >>>> This diff file shows all changes made to date:
> >>>> https://www.rfc-editor.org/authors/rfc9527-diff.html
> >>>> <https://www.rfc-editor.org/authors/rfc9527-diff.html>
> >>>> For the AUTH48 status of this document, please see:
> >>>> https://www.rfc-editor.org/auth48/rfc9527 <https://www.rfc-
> >>>> editor.org/auth48/rfc9527>
> >>>> Best regards,
> >>>> RFC Editor/kc
> >>>>> On Jan 12, 2024, at 8:45 AM, Daniel Migault
> >>>>> <[e-mail]
> >>>>> <mailto:[e-mail]>> wrote:
> >>>>>
> >>>>> Thanks for the review. I agree/approve the changes.
> >>>>>
> >>>>> Yours,
> >>>>> Daniel
> >>>>> On Jan 12, 2024, at 8:08 AM, Tomek Mrugalski
> >>>>> <[e-mail] <mailto:[e-mail]>>
> >>>>> wrote:
> >>>>>
> >>>>> Hi,
> >>>>> Apologies for my review taking so long. Life seems to always get
> >>>>> in the
> >>>>> way and I wanted to be thorough. I have reviewed the text and
> >>>>> would like
> >>>>> to propose the following changes. None of them provide any
> >>>>> substantial
> >>>>> changes, just clarifications.
> >>>>>
> >>>>> 1. Section 1:
> >>>>>
> >>>>> As written, the text below can be interpreted as the IP prefix
> >>>>> being
> >>>>> delegated to associated reverse zone. That doesn't sound right. I
> >>>>> think
> >>>>> it should be clarified. Here's my proposal. Since I'm not a DNS
> >>>>> expert,
> >>>>> I'll gladly accept any other alternative.
> >>>>>
> >>>>> OLD:
> >>>>> The ISP delegates an IP prefix to the home network as
> >>>>> well as to the associated reverse zone.
> >>>>>
> >>>>> NEW:
> >>>>> The ISP delegates an IP prefix and the associated reverse zone to
> >>>>> the
> >>>>> home network.
> >>>>>
> >>>>> --------------
> >>>>>
> >>>>> 2. Section 4.4 and and Table 2 in Section 6.2
> >>>>>
> >>>>> My concern here is about the bits. My understanding is that we
> >>>>> want to
> >>>>> associate bit 0 (least significant bit) with DomTLS and let
> >>>>> future RFCs
> >>>>> possibly define other bits. I think the left to right (or "L to
> >>>>> R" as
> >>>>> written in ) is confusing. It should be LSB to MSB (least to most
> >>>>> significant).
> >>>>>
> >>>>> OLD:
> >>>>> | Bit Position | Transport Protocol | Mnemonic | Reference |
> >>>>> | (L to R) | Description | | |
> >>>>>
> >>>>> NEW:
> >>>>> | Bit Position | Transport Protocol | Mnemonic | Reference |
> >>>>> | (Least to most signif.)| Description | | |
> >>>>>
> >>>>> --------------
> >>>>>
> >>>>> 3. Sections 4.2 and 4.3
> >>>>>
> >>>>> When viewing the txt version
> >>>>> (https://www.rfc-editor.org/authors/rfc9527.txt <https://www.rfc-
> >>>>> editor.org/authors/rfc9527.txt>), the upper line has 2
> >>>>> and 3 off by couple spaces. I've
> >>>>> checked this in my browser and with text editor. The same minor
> >>>>> mistake
> >>>>> appears in both section 4.2 and 4.3 (section 4.1 is ok).
> >>>>>
> >>>>> OLD:
> >>>>> 0 1 2 3
> >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>>
> >>>>> NEW:
> >>>>> 0 1 2 3
> >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>>
> >>>>> 4. Section 4.4:
> >>>>>
> >>>>> OLD:
> >>>>> (missing example)
> >>>>>
> >>>>> NEW:
> >>>>> As an example, the Supported transport field expressing support
> >>>>> for
> >>>>> DomTLS looks as follows and has numeric value of 0x0001:
> >>>>>
> >>>>> 0 1
> >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>> | must-be-zero |1|
> >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>>
> >>>>> ------
> >>>>>
> >>>>> Explanation: Good to be consistent with existing RFCs, such as
> >>>>> RFC4704,
> >>>>> Section 4.1. It defines bit field for FQDN option and the bits N
> >>>>> (4),
> >>>>> O(2) and S(1) are presented this way:
> >>>>>
> >>>>> 0 1 2 3 4 5 6 7
> >>>>> +-+-+-+-+-+-+-+-+
> >>>>> | MBZ |N|O|S|
> >>>>> +-+-+-+-+-+-+-+-+
> >>>>>
> >>>>> -------------------
> >>>>>
> >>>>> 5. Acknowledgements:
> >>>>>
> >>>>> OLD:
> >>>>> The designed solution has been largely been inspired by Mark
> >>>>> Andrews's
> >>>>> document...
> >>>>>
> >>>>> NEW:
> >>>>> The designed solution has largely been inspired by Mark Andrews's
> >>>>> document...
> >>>>>
> >>>>> -------------------
> >>>>>
> >>>>> 6. Authors' addresses:
> >>>>>
> >>>>> OLD:
> >>>>> Tomek Mrugalski
> >>>>> Internet Systems Consortium, Inc.
> >>>>> 950 Charter Street
> >>>>> Redwood City, CA 94063
> >>>>> United States of America
> >>>>> Email: [e-mail]
> >>>>> <mailto:[e-mail]>
> >>>>>
> >>>>> NEW:
> >>>>> Tomek Mrugalski
> >>>>> Internet Systems Consortium, Inc.
> >>>>> PO Box 360
> >>>>> Newmarket, NH 03857
> >>>>> United States of America
> >>>>> Email: [e-mail]
> >>>>> <mailto:[e-mail]>
> >>>>>
> >>>>> --------------------
> >>>>>
> >>>>> 7. Front page:
> >>>>>
> >>>>> OLD:
> >>>>> Internet Systems Consortium, Inc.
> >>>>>
> >>>>> NEW:
> >>>>> ISC
> >>>>>
> >>>>>
> >>>>> I also approve all earlier changes that were already applied.
> >>>>>
> >>>>> Thanks,
> >>>>> Tomek
> >>>>>
> >>>>> On 11.01.2024 21:07, Karen Moore wrote:
> >>>>>> Hi Daniel,
> >>>>>>
> >>>>>> We have updated 2 instances of “DHCP Option” to “DHCPv6 option”
> >>>>>> in the text. The updated files are below.
> >>>>>>
> >>>>>> The updated XML file is here:
> >>>>>> https://www.rfc-editor.org/authors/rfc9527.xml <https://www.rfc-
> >>>>>> editor.org/authors/rfc9527.xml>
> >>>>>>
> >>>>>> The updated output files are here:
> >>>>>> https://www.rfc-editor.org/authors/rfc9527.txt <https://www.rfc-
> >>>>>> editor.org/authors/rfc9527.txt>
> >>>>>> https://www.rfc-editor.org/authors/rfc9527.pdf <https://www.rfc-
> >>>>>> editor.org/authors/rfc9527.pdf>
> >>>>>> https://www.rfc-editor.org/authors/rfc9527.html
> >>>>>> <https://www.rfc-editor.org/authors/rfc9527.html>
> >>>>>>
> >>>>>> This diff file shows all changes made during AUTH48:
> >>>>>> https://www.rfc-editor.org/authors/rfc9527-auth48diff.html
> >>>>>> <https://www.rfc-editor.org/authors/rfc9527-auth48diff.html>
> >>>>>>
> >>>>>> This diff file shows only the changes made during the last edit
> >>>>>> round:
> >>>>>> https://www.rfc-editor.org/authors/rfc9527-lastrfcdiff.html
> >>>>>> <https://www.rfc-editor.org/authors/rfc9527-lastrfcdiff.html>
> >>>>>>
> >>>>>> This diff file shows all changes made to date:
> >>>>>> https://www.rfc-editor.org/authors/rfc9527-diff.html
> >>>>>> <https://www.rfc-editor.org/authors/rfc9527-diff.html>
> >>>>>>
> >>>>>> For the AUTH48 status of this document, please see:
> >>>>>> https://www.rfc-editor.org/auth48/rfc9527 <https://www.rfc-
> >>>>>> editor.org/auth48/rfc9527>
> >>>>>>
> >>>>>> As previously mentioned, we will await Tomek’s approval (or
> >>>>>> comments) prior to moving forward with publication.
> >>>>>>
> >>>>>> Best regards,
> >>>>>> RFC Editor/kc
> >>>>>>
> >>>>>>
> >>>>>>> On Jan 10, 2024, at 1:22 PM, Daniel Migault
> >>>>>>> <[e-mail]
> >>>>>>> <mailto:[e-mail]>> wrote:
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I am fine with DHCPv6 option" as well as any further changes
> >>>>>>> submitted by other co-authors.
> >>>>>>>
> >>>>>>> Yours,
> >>>>>>> Daniel
> >>>>>>>
> >>>>>>> ________________________________________
> >>>>>>> From: Karen Moore <[e-mail] <mailto:[e-mail]>>
> >>>>>>> Sent: Wednesday, January 10, 2024 3:22 PM
> >>>>>>> To: Daniel Migault; [e-mail]
> >>>>>>> <mailto:[e-mail]>; [e-mail]
> >>>>>>> <mailto:[e-mail]>
> >>>>>>> Cc: [e-mail] <mailto:rfc-editor@rfc-
> >>>>>>> editor.org>; [e-mail] <mailto:homenet-
> >>>>>>> [e-mail]>; [e-mail] <mailto:homenet-
> >>>>>>> [e-mail]>; [e-mail]
> >>>>>>> <mailto:[e-mail]>; [e-mail]
> >>>>>>> <mailto:[e-mail]>; [e-mail]
> >>>>>>> <mailto:[e-mail]>
> >>>>>>> Subject: Re: AUTH48: RFC-to-be 9527 <draft-ietf-homenet-naming-
> >>>>>>> architecture-dhc-options-24> for your review
> >>>>>>>
> >>>>>>> Hello Daniel and Tomek,
> >>>>>>>
> >>>>>>> Thank you for your replies regarding “DHCPv6 Options”. Please
> >>>>>>> note that the majority of RFCs use “options” (lowercased);
> >>>>>>> given this, may we update the text to reflect “DHCPv6 options”
> >>>>>>> for consistency, which would also match use in RFC 7227?
> >>>>>>>
> >>>>>>> Daniel, we noted your approval of the document on the AUTH48
> >>>>>>> status page (https://www.rfc-editor.org/auth48/rfc9527
> >>>>>>> <https://www.rfc-editor.org/auth48/rfc9527>). We will assume
> >>>>>>> your approval stands even if your coauthor submits further
> >>>>>>> changes unless we hear otherwise at that time.
> >>>>>>>
> >>>>>>> Tomek, we will await your approval (or comments) prior to
> >>>>>>> moving forward with publication.
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> RFC Editor/kc
> >>>>>>>
> >>>>>>>> On Jan 10, 2024, at 9:37 AM, Tomek Mrugalski
> >>>>>>>> <[e-mail]
> >>>>>>>> <mailto:[e-mail]>> wrote:
> >>>>>>>>
> >>>>>>>> On 9.01.2024 03:25, Daniel Migault wrote:
> >>>>>>>>> I approve the changes. I checked with the DHCP WG chairs some
> >>>>>>>>> guidance regarding the use of "DHCPv6 option" or "DHCP
> >>>>>>>>> Option”. There response is:
> >>>>>>>>>
> >>>>>>>>> """
> >>>>>>>>> I would use dhcpv6 option to make it clear that it is for
> >>>>>>>>> ipv6.
> >>>>>>>>>
> >>>>>>>>> If the document is all and only about ipv6, you could use
> >>>>>>>>> dhcp.
> >>>>>>>>> """
> >>>>>>>>>
> >>>>>>>>> I tend to say DHCPv6 option seems at least fine and propose
> >>>>>>>>> we adopt that terminology.
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> Apologies for late response. My personal preference is DHCPv6
> >>>>>>>> Options.
> >>>>>>>> It's clear that it applies to DHCPv6 only. The "DHCP options"
> >>>>>>>> in some
> >>>>>>>> contexts can be interpreted as "either DHCPv4 or DHCPv6
> >>>>>>>> options". And
> >>>>>>>> that's not what we want to say here.
> >>>>>>>>
> >>>>>>>> I've started reviewing the I-D. I'll post my approval (or
> >>>>>>>> comments)
> >>>>>>>> soon. Hopefully tomorrow.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Tomek
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Jan 8, 2024, at 6:25 PM, Daniel Migault
> >>>>>>>> <[e-mail]
> >>>>>>>> <mailto:[e-mail]>> wrote:
> >>>>>>>>
> >>>>>>>> I approve the changes. I checked with the DHCP WG chairs some
> >>>>>>>> guidance regarding the use of "DHCPv6 option" or "DHCP
> >>>>>>>> Option”. There response is:
> >>>>>>>>
> >>>>>>>> """
> >>>>>>>> I would use dhcpv6 option to make it clear that it is for
> >>>>>>>> ipv6.
> >>>>>>>>
> >>>>>>>> If the document is all and only about ipv6, you could use
> >>>>>>>> dhcp.
> >>>>>>>> """
> >>>>>>>>
> >>>>>>>> I tend to say DHCPv6 option seems at least fine and propose we
> >>>>>>>> adopt that terminology.
> >>>>>>>>
> >>>>>>>> Yours,
> >>>>>>>> Daniel
> >>>>>>>>
> >>>>>>>> ________________________________________
> >>>>>>>> From: Karen Moore <[e-mail] <mailto:[e-mail]>>
> >>>>>>>> Sent: Monday, January 8, 2024 3:49 PM
> >>>>>>>> To: Daniel Migault; [e-mail]
> >>>>>>>> <mailto:[e-mail]>; [e-mail]
> >>>>>>>> <mailto:[e-mail]>
> >>>>>>>> Cc: [e-mail] <mailto:rfc-editor@rfc-
> >>>>>>>> editor.org>; [e-mail] <mailto:homenet-
> >>>>>>>> [e-mail]>; [e-mail] <mailto:homenet-
> >>>>>>>> [e-mail]>; [e-mail]
> >>>>>>>> <mailto:[e-mail]>; [e-mail]
> >>>>>>>> <mailto:[e-mail]>; [e-mail]
> >>>>>>>> <mailto:[e-mail]>
> >>>>>>>> Subject: Re: AUTH48: RFC-to-be 9527 <draft-ietf-homenet-
> >>>>>>>> naming-architecture-dhc-options-24> for your review
> >>>>>>>>
> >>>>>>>> Hi Ralf,
> >>>>>>>>
> >>>>>>>> Thank you for your reply. We have noted your approval on the
> >>>>>>>> AUTH48 status page for this document (https://www.rfc-
> >>>>>>>> editor.org/auth48/rfc9527 <https://www.rfc-
> >>>>>>>> editor.org/auth48/rfc9527>).
> >>>>>>>>
> >>>>>>>> Please note that we await a reply from one of the coauthors
> >>>>>>>> regarding the use of "DHCPv6 option" or "DHCP Option” for
> >>>>>>>> consistency.
> >>>>>>>>
> >>>>>>>>> [DM] I am wondering what are the guidance in using DHCP
> >>>>>>>>> Options versus DHCPv6 option. I have the impression 8415 uses
> >>>>>>>>> DHCP Options while 7227 uses "DHCPv6 option.
> >>>>>>>>
> >>>>>>>> We also wait approvals from Daniel and Tomek prior to moving
> >>>>>>>> forward with publication.
> >>>>>>>>
> >>>>>>>> Best regards,
> >>>>>>>> RFC Editor/kc
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Jan 7, 2024, at 3:51 AM, Ralf Weber
> >>>>>>>>> <ralf.weber=[e-mail]
> >>>>>>>>> <mailto:[e-mail]>> wrote:
> >>>>>>>>>
> >>>>>>>>> Moin!
> >>>>>>>>>
> >>>>>>>>> On 19 Dec 2023, at 6:58, [e-mail]
> >>>>>>>>> <mailto:[e-mail]> wrote:
> >>>>>>>>>
> >>>>>>>>>> *****IMPORTANT*****
> >>>>>>>>>>
> >>>>>>>>>> Updated 2023/12/18
> >>>>>>>>>>
> >>>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>> I approve publication.
> >>>>>>>>>
> >>>>>>>>> Sorry for the late reply that went under in the pre holiday
> >>>>>>>>> preparations.
> >>>>>>>>>
> >>>>>>>>> So long
> >>>>>>>>> -Ralf
> >>>>>>>>> ---
> >>>>>>>>> Ralf Weber
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Dec 21, 2023, at 1:06 PM, Karen Moore <[e-mail]
> >>>>>>>>> <mailto:[e-mail]>> wrote:
> >>>>>>>>>
> >>>>>>>>> Hello Daniel,
> >>>>>>>>>
> >>>>>>>>> Thank you for your reply. We have updated our files
> >>>>>>>>> accordingly. Please note that we will hold on making updates
> >>>>>>>>> regarding "DHCPv6 option vs. DHCP Option” until we hear from
> >>>>>>>>> your coauthor(s) (your question is included below for easy
> >>>>>>>>> reference).
> >>>>>>>>>
> >>>>>>>>>> [DM] I am wondering what are the guidance in using DHCP
> >>>>>>>>>> Options versus DHCPv6 option. I have the impression 8415
> >>>>>>>>>> uses DHCP Options while 7227 uses "DHCPv6 option.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> FILES
> >>>>>>>>>
> >>>>>>>>> The updated XML file is here:
> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9527.xml
> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9527.xml>
> >>>>>>>>>
> >>>>>>>>> The updated output files are here:
> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9527.txt
> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9527.txt>
> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9527.pdf
> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9527.pdf>
> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9527.html
> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9527.html>
> >>>>>>>>>
> >>>>>>>>> This diff file shows all changes made during AUTH48:
> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9527-auth48diff.html
> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9527-auth48diff.html>
> >>>>>>>>>
> >>>>>>>>> This diff file shows all changes made to date:
> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9527-diff.html
> >>>>>>>>> <https://www.rfc-editor.org/authors/rfc9527-diff.html>
> >>>>>>>>>
> >>>>>>>>> Note that it may be necessary for you to refresh your browser
> >>>>>>>>> to view the most recent version. Please review the document
> >>>>>>>>> carefully to ensure satisfaction as we do not make changes
> >>>>>>>>> once it has been published as an RFC.
> >>>>>>>>>
> >>>>>>>>> Please contact us with any further updates or with your
> >>>>>>>>> approval of the document in its current form. We will await
> >>>>>>>>> approvals from each author prior to moving forward in the
> >>>>>>>>> publication process.
> >>>>>>>>>
> >>>>>>>>> For the AUTH48 status of this document, please see:
> >>>>>>>>> https://www.rfc-editor.org/auth48/rfc9527 <https://www.rfc-
> >>>>>>>>> editor.org/auth48/rfc9527>
> >>>>>>>>>
> >>>>>>>>> Thank you,
> >>>>>>>>> RFC Editor/kc
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On Dec 19, 2023, at 8:39 AM, Daniel Migault
> >>>>>>>>>> <daniel.migault=[e-mail]
> >>>>>>>>>> <mailto:[e-mail]>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> Thank you for reviewing the document. There is one remaining
> >>>>>>>>>> question I would like to ask CCed people.
> >>>>>>>>>>
> >>>>>>>>>> I am wondering what are the guidance in using DHCP Options
> >>>>>>>>>> versus DHCPv6 option. I have the impression 8415 uses DHCP
> >>>>>>>>>> Options while 7227 uses "DHCPv6 option.
> >>>>>>>>>>
> >>>>>>>>>> Yours,
> >>>>>>>>>> Daniel
> >>>>>>>>>>
> >>>>>>>>>> ________________________________________
> >>>>>>>>>> From: [e-mail] <mailto:rfc-editor@rfc-
> >>>>>>>>>> editor.org> <[e-mail] <mailto:rfc-
> >>>>>>>>>> [e-mail]>>
> >>>>>>>>>> Sent: Tuesday, December 19, 2023 12:59 AM
> >>>>>>>>>> To: Daniel Migault; [e-mail]
> >>>>>>>>>> <mailto:[e-mail]>; [e-mail]
> >>>>>>>>>> <mailto:[e-mail]>
> >>>>>>>>>> Cc: [e-mail] <mailto:rfc-editor@rfc-
> >>>>>>>>>> editor.org>; [e-mail] <mailto:homenet-
> >>>>>>>>>> [e-mail]>; [e-mail] <mailto:homenet-
> >>>>>>>>>> [e-mail]>; [e-mail]
> >>>>>>>>>> <mailto:[e-mail]>; [e-mail]
> >>>>>>>>>> <mailto:[e-mail]>; [e-mail]
> >>>>>>>>>> <mailto:[e-mail]>
> >>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9527 <draft-ietf-homenet-
> >>>>>>>>>> naming-architecture-dhc-options-24> for your review
> >>>>>>>>>>
> >>>>>>>>>> Authors,
> >>>>>>>>>>
> >>>>>>>>>> While reviewing this document during AUTH48, please resolve
> >>>>>>>>>> (as necessary) the following questions, which are also in
> >>>>>>>>>> the XML file.
> >>>>>>>>>>
> >>>>>>>>>> 1) <!--[rfced] Should "Home Network" be updated to "Homenet"
> >>>>>>>>>> in the
> >>>>>>>>>> document title to more closely match the terminology used in
> >>>>>>>>>> the
> >>>>>>>>>> Abstract and Introduction? Please let us know your
> >>>>>>>>>> preference.
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> DHCPv6 Options for Home Network Naming Authority
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>> DHCPv6 Options for the Homenet Naming Authority
> >>>>>>>>>> -->
> >>>>>>>>>> <mglt>
> >>>>>>>>>> This seems appropriated and more consistent.
> >>>>>>>>>> <mglt>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those
> >>>>>>>>>> that appear in
> >>>>>>>>>> the title) for use on https://www.rfc-editor.org/search
> >>>>>>>>>> <https://www.rfc-editor.org/search>. -->
> >>>>>>>>>>
> >>>>>>>>>> <mglt>
> >>>>>>>>>> I think this is correct, maybe DNS
> >>>>>>>>>> </mglt>
> >>>>>>>>>>
> >>>>>>>>>> 3) <!--[rfced] Please clarify "proceed to the
> >>>>>>>>>> configuration". Is the intended
> >>>>>>>>>> meaning that the HNA can proceed to "use", "set", or
> >>>>>>>>>> "identify" the
> >>>>>>>>>> appropriate configuration?
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> This document defines DHCPv6 options so a Homenet Naming
> >>>>>>>>>> Authority
> >>>>>>>>>> (HNA) can automatically proceed to the appropriate
> >>>>>>>>>> configuration and
> >>>>>>>>>> outsource the authoritative naming service for the home
> >>>>>>>>>> network.
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>> This document defines DHCPv6 options so that a Homenet
> >>>>>>>>>> Naming Authority
> >>>>>>>>>> (HNA) can automatically use the appropriate configuration
> >>>>>>>>>> and
> >>>>>>>>>> outsource the authoritative naming service for the home
> >>>>>>>>>> network.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> <mglt>
> >>>>>>>>>> I think that "set" woudl be more appropriated, so the change
> >>>>>>>>>> woudl be more:
> >>>>>>>>>>
> >>>>>>>>>> NEW:
> >>>>>>>>>> This document defines DHCPv6 options so that a Homenet
> >>>>>>>>>> Naming Authority
> >>>>>>>>>> (HNA) can automatically set the appropriate configuration
> >>>>>>>>>> and
> >>>>>>>>>> outsource the authoritative naming service for the home
> >>>>>>>>>> network.
> >>>>>>>>>> </mglt>
> >>>>>>>>>>
> >>>>>>>>>> 4) <!--[rfced] Is "necessary information on the DM and RDM"
> >>>>>>>>>> referring to
> >>>>>>>>>> the Registered Homenet Domain (option A) or what the ISP
> >>>>>>>>>> provides (option B)? Please clarify.
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> More specifically,
> >>>>>>>>>> the ISP provides the Registered Homenet Domain, necessary
> >>>>>>>>>> information
> >>>>>>>>>> on the DM and the RDM so the HNA can manage and upload the
> >>>>>>>>>> Public
> >>>>>>>>>> Homenet Zone and the Reverse Public Homenet Zone as
> >>>>>>>>>> described in
> >>>>>>>>>> [I-D.ietf-homenet-front-end-naming-delegation].
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>> A) More specifically,
> >>>>>>>>>> the ISP provides the Registered Homenet Domain, which
> >>>>>>>>>> includes necessary
> >>>>>>>>>> information on the DM and the RDM, so the HNA can manage and
> >>>>>>>>>> upload the
> >>>>>>>>>> Public Homenet Zone and the Reverse Public Homenet Zone as
> >>>>>>>>>> described in
> >>>>>>>>>> [RFC9526].
> >>>>>>>>>> or
> >>>>>>>>>>
> >>>>>>>>>> B) More specifically,
> >>>>>>>>>> the ISP provides the Registered Homenet Domain and the
> >>>>>>>>>> necessary
> >>>>>>>>>> information on the DM and the RDM so the HNA can manage and
> >>>>>>>>>> upload
> >>>>>>>>>> the Public Homenet Zone and the Reverse Public Homenet Zone
> >>>>>>>>>> as
> >>>>>>>>>> described in [RFC9526].
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> <mglt>
> >>>>>>>>>> Option B is I think what we meant.
> >>>>>>>>>> </mglt>
> >>>>>>>>>>
> >>>>>>>>>> 5) <!--[rfced] FYI: we moved the Terminology section after
> >>>>>>>>>> the
> >>>>>>>>>> Introduction per Section 4 of RFC 7322 ("RFC Style Guide").
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> <mglt>
> >>>>>>>>>> ok.
> >>>>>>>>>> </mglt>
> >>>>>>>>>>
> >>>>>>>>>> 6) <!--[rfced] Regarding "DNS over mutually authenticated
> >>>>>>>>>> TLS [RFC7858]". Is citing RFC 7858 accurate here? We see RFC
> >>>>>>>>>> 7858
> >>>>>>>>>> is about DNS over TLS, without the words "mutually
> >>>>>>>>>> authenticated"
> >>>>>>>>>> or "mutual authentication" appearing within the document.
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> The bit for DNS over mutually authenticated TLS [RFC7858]
> >>>>>>>>>> MUST be set.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> <mglt>
> >>>>>>>>>> yes, this is the correct reference. TLS makes possible
> >>>>>>>>>> mutual authentication or not.
> >>>>>>>>>> </mglt>
> >>>>>>>>>>
> >>>>>>>>>> 7) <!--[rfced] We notice that Table 1 (Section 4.4) and
> >>>>>>>>>> Table 3 (Section
> >>>>>>>>>> 6.2) are exactly the same. We suggest Table 1 be removed and
> >>>>>>>>>> the text
> >>>>>>>>>> be updated to point to Table 3 as shown below; is this
> >>>>>>>>>> acceptable?
> >>>>>>>>>>
> >>>>>>>>>> (Section 4.4)
> >>>>>>>>>> Original:
> >>>>>>>>>> The Supported Transport field of the DHCPv6 option indicates
> >>>>>>>>>> the
> >>>>>>>>>> supported transport protocols. Each bit represents a
> >>>>>>>>>> specific
> >>>>>>>>>> transport mechanism. A bit sets to 1 indicates the
> >>>>>>>>>> associated
> >>>>>>>>>> transport protocol is supported. The corresponding bits are
> >>>>>>>>>> assigned as described in Figure 4 and Section 6.
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>> The Supported Transport field of the DHCPv6 option indicates
> >>>>>>>>>> the
> >>>>>>>>>> Supported Transport protocols. Each bit represents a
> >>>>>>>>>> specific
> >>>>>>>>>> transport mechanism. A bit set to 1 indicates the associated
> >>>>>>>>>> transport protocol is supported. The corresponding bits are
> >>>>>>>>>> assigned as described in Table 3.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> <mglt>
> >>>>>>>>>> sure ;-)
> >>>>>>>>>> </mglt>
> >>>>>>>>>>
> >>>>>>>>>> 8) <!--[rfced] RFC 8415 does not contain Section 17.2.2. Is
> >>>>>>>>>> Section 17.2
> >>>>>>>>>> ("Source Address and Interface Selection for Prefix
> >>>>>>>>>> Delegation")
> >>>>>>>>>> the correct section? Please confirm.
> >>>>>>>>>>
> >>>>>>>>>> Current:
> >>>>>>>>>> Sections 17.2.2 and 18.2 of [RFC8415] govern server
> >>>>>>>>>> operation
> >>>>>>>>>> regarding option assignment.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> <mglt>
> >>>>>>>>>> I think this is:
> >>>>>>>>>>
> >>>>>>>>>> NEW:
> >>>>>>>>>> 18.3 of [RFC8415] govern server operation
> >>>>>>>>>> regarding option assignment.
> >>>>>>>>>> </mglt>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 9) <!--[rfced] We do not see mention of "Option Request
> >>>>>>>>>> Option" or "ORO"
> >>>>>>>>>> in Section 18.2.5 of RFC 8415. Is the reference correct or
> >>>>>>>>>> is an
> >>>>>>>>>> update needed to the text?
> >>>>>>>>>>
> >>>>>>>>>> Current:
> >>>>>>>>>> The DHCPv6 client includes the Registered Homenet Domain
> >>>>>>>>>> Option,
> >>>>>>>>>> Distribution Manager Option, and Reverse Distribution
> >>>>>>>>>> Manager Option
> >>>>>>>>>> in an ORO as specified in Sections 18.2.1, 18.2.2, 18.2.4,
> >>>>>>>>>> 18.2.5,
> >>>>>>>>>> 18.2.6, and 21.7 of [RFC8415].
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> <mglt>
> >>>>>>>>>> The DHCPv6 client includes the Registered Homenet Domain
> >>>>>>>>>> Option,
> >>>>>>>>>> Distribution Manager Option, and Reverse Distribution
> >>>>>>>>>> Manager Option
> >>>>>>>>>> in an ORO as specified in Sections 18.2 and 21.7of
> >>>>>>>>>> [RFC8415].
> >>>>>>>>>> </mglt>
> >>>>>>>>>>
> >>>>>>>>>> 10) <!--[rfced] Please clarify "once-for-ever". Could this
> >>>>>>>>>> be rephrased as follows
> >>>>>>>>>> for clarity?
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> Again, this configuration update is done once-for-ever.
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>> Again, this configuration update only needs to be performed
> >>>>>>>>>> one time.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> <mglt>
> >>>>>>>>>> This seems fine to me.
> >>>>>>>>>> </mglt>
> >>>>>>>>>>
> >>>>>>>>>> 11) <!-- [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.
> >>>>>>>>>>
> >>>>>>>>>> DHCPv6 option vs. DHCP Option
> >>>>>>>>>>
> >>>>>>>>>> <mglt>
> >>>>>>>>>> 8415 uses DHCP Option, so I suppose this is fine to use that
> >>>>>>>>>> here as well.
> >>>>>>>>>> </mglt>
> >>>>>>>>>>
> >>>>>>>>>> Zero Configuration vs. zero-config
> >>>>>>>>>> [Are these terms the same or different? If "Zero
> >>>>>>>>>> Configuration"
> >>>>>>>>>> is used, should it be lowercase?]
> >>>>>>>>>>
> >>>>>>>>>> <mglt>
> >>>>>>>>>> I am fine using zero configuration.
> >>>>>>>>>> </mglt>
> >>>>>>>>>>
> >>>>>>>>>> b) We updated the text to reflect the latter terms below for
> >>>>>>>>>> consistency
> >>>>>>>>>> (and the number of instances is in parentheses for
> >>>>>>>>>> reference). Please
> >>>>>>>>>> let us know if any further updates are needed.
> >>>>>>>>>>
> >>>>>>>>>> Base Scenario -> base scenario (1)
> >>>>>>>>>> DHCPv6 Option -> DHCPv6 option (2)
> >>>>>>>>>>
> >>>>>>>>>> <mglt>
> >>>>>>>>>> I am fine with DHCP(v6) (O/o)ption. I have the impression
> >>>>>>>>>> 8415 is using DHCPv6 in the title and then talks only about
> >>>>>>>>>> DHCP Options. 7227 uses "DHCPv6 option".
> >>>>>>>>>> </mglt>
> >>>>>>>>>>
> >>>>>>>>>> Forward Distributed Manager Option -> Forward Distribution
> >>>>>>>>>> Manager Option (1)
> >>>>>>>>>> Homenet Registered Domain -> Registered Homenet Domain (2)
> >>>>>>>>>> Information -> information (1)
> >>>>>>>>>> supported transport -> Supported Transport (4) (per RFC-to-
> >>>>>>>>>> be 9526)
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> <mglt>
> >>>>>>>>>> That seems fine to be.
> >>>>>>>>>>
> >>>>>>>>>> </mglt>
> >>>>>>>>>>
> >>>>>>>>>> 12) <!--[rfced] Abbreviations
> >>>>>>>>>>
> >>>>>>>>>> a) We have added expansions for the following abbreviations
> >>>>>>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please
> >>>>>>>>>> review each
> >>>>>>>>>> expansion in the document carefully to ensure correctness.
> >>>>>>>>>>
> >>>>>>>>>> fully qualified domain name (FQDN) (per RFC-to-be 9526)
> >>>>>>>>>>
> >>>>>>>>>> b) The expansion for "CPE" in this document (i.e., "Customer
> >>>>>>>>>> Edge (CPE)")
> >>>>>>>>>> does not match the expansion in RFC 7368 and RFC-to-be 9526
> >>>>>>>>>> (i.e.,
> >>>>>>>>>> "Customer Premises Equipment (CPE)"). Please let us know
> >>>>>>>>>> which form is
> >>>>>>>>>> preferred. Note that the acronym for "Customer Edge" is
> >>>>>>>>>> "(CE)".
> >>>>>>>>>>
> >>>>>>>>>> Customer Edge (CPE) vs. Customer Premises Equipment (CPE)
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> <mglt>
> >>>>>>>>>> I beleive we can use Customer Premises Equipment (CPE)
> >>>>>>>>>> </mglt>
> >>>>>>>>>> 13) <!-- [rfced] Please review the "Inclusive Language"
> >>>>>>>>>> portion of the online
> >>>>>>>>>> Style Guide <https://www.rfc-
> >>>>>>>>>> editor.org/styleguide/part2/#inclusive_language>
> >>>>>>>>>> <https://www.rfc-
> >>>>>>>>>> editor.org/styleguide/part2/#inclusive_language&gt;>
> >>>>>>>>>> and let us know if any changes are needed.
> >>>>>>>>>>
> >>>>>>>>>> Note that our script did not flag any words in particular,
> >>>>>>>>>> but this should
> >>>>>>>>>> still be reviewed as a best practice.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thank you.
> >>>>>>>>>>
> >>>>>>>>>> RFC Editor/kc/ar
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Dec 18, 2023, [e-mail] <mailto:rfc-
> >>>>>>>>>> [e-mail]> wrote:
> >>>>>>>>>>
> >>>>>>>>>> *****IMPORTANT*****
> >>>>>>>>>>
> >>>>>>>>>> Updated 2023/12/18
> >>>>>>>>>>
> >>>>>>>>>> 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/ <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/
> >>>>>>>>>> <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>
> >>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary&gt;>.
> >>>>>>>>>>
> >>>>>>>>>> * 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] <mailto:rfc-editor@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).
> >>>>>>>>>>
> >>>>>>>>>> * [e-mail] <mailto: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
> >>>>>>>>>> <https://mailarchive.ietf.org/arch/msg/ietf-
> >>>>>>>>>> announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>
> >>>>>>>>>>
> >>>>>>>>>> * The archive itself:
> >>>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/
> >>>>>>>>>> <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] <mailto: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/rfc9527.xml
> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9527.xml>
> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9527.html
> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9527.html>
> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9527.pdf
> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9527.pdf>
> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9527.txt
> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9527.txt>
> >>>>>>>>>>
> >>>>>>>>>> Diff file of the text:
> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9527-diff.html
> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9527-diff.html>
> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9527-rfcdiff.html
> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9527-rfcdiff.html>
> >>>>>>>>>> (side by side)
> >>>>>>>>>>
> >>>>>>>>>> This alternative diff file shows the changes in the moved
> >>>>>>>>>> text:
> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9527-alt-diff.html
> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9527-alt-diff.html>
> >>>>>>>>>>
> >>>>>>>>>> Diff of the XML:
> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9527-xmldiff1.html
> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9527-xmldiff1.html>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> The following files are provided to facilitate creation of
> >>>>>>>>>> your own
> >>>>>>>>>> diff files of the XML.
> >>>>>>>>>>
> >>>>>>>>>> Initial XMLv3 created using XMLv2 as input:
> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9527.original.v2v3.xml
> >>>>>>>>>> <https://www.rfc-
> >>>>>>>>>> editor.org/authors/rfc9527.original.v2v3.xml>
> >>>>>>>>>>
> >>>>>>>>>> XMLv3 file that is a best effort to capture v3-related
> >>>>>>>>>> format updates
> >>>>>>>>>> only:
> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9527.form.xml
> >>>>>>>>>> <https://www.rfc-editor.org/authors/rfc9527.form.xml>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Tracking progress
> >>>>>>>>>> -----------------
> >>>>>>>>>>
> >>>>>>>>>> The details of the AUTH48 status of your document are here:
> >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9527 <https://www.rfc-
> >>>>>>>>>> editor.org/auth48/rfc9527>
> >>>>>>>>>>
> >>>>>>>>>> Please let us know if you have any questions.
> >>>>>>>>>>
> >>>>>>>>>> Thank you for your cooperation,
> >>>>>>>>>>
> >>>>>>>>>> RFC Editor
> >>>>>>>>>>
> >>>>>>>>>> --------------------------------------
> >>>>>>>>>> RFC9527 (draft-ietf-homenet-naming-architecture-dhc-options-
> >>>>>>>>>> 24)
> >>>>>>>>>>
> >>>>>>>>>> Title : DHCPv6 Options for Home Network Naming Authority
> >>>>>>>>>> Author(s) : D. Migault, R. Weber, T. Mrugalski
> >>>>>>>>>> WG Chair(s) : Kiran Makhijani, Stephen Farrell
> >>>>>>>>>> Area Director(s) : Erik Kline, Éric Vyncke
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
> >>
> >>
> >>
> >>
> >>
> >