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

[Daniel Migault <[e-mail]>]

Thanks!

-----Original Message-----
From: Eric Vyncke (evyncke) <[e-mail]> 
Sent: January 18, 2024 8:33 AM
To: Karen Moore <[e-mail]>; Tomek Mrugalski <[e-mail]>; [e-mail]; Daniel Migault <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [AD] AUTH48: RFC-to-be 9527 <draft-ietf-homenet-naming-architecture-dhc-options-24> for your review

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:[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: 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:[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: 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:[e-mail]> <[e-mail] 
>>>>>>>> <mailto:[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:[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: 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_languag
>>>>>>>> e> 
>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_languag
>>>>>>>> e&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:[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:[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] 
>>>>>>>> <mailto:[e-mail]>, 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-4Q
>>>>>>>> 9l2USxIAe6P8O4Zc 
>>>>>>>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4
>>>>>>>> Q9l2USxIAe6P8O4Zc>
>>>>>>>> 
>>>>>>>> * 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:[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/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
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>