Re: [auth48] [AD] AUTH48: RFC-to-be 9526 <draft-ietf-homenet-front-end-naming-delegation-27> for your review

[Karen Moore <[e-mail]>]

Hi Daniel,

We have noted your approval on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9526).

We now await approvals from Michael and Ray and approval of the changes outlined below from Éric.

Best regards,
RFC Editor/kc


> On Jan 8, 2024, at 6:27 PM, Daniel Migault <daniel.migault=[e-mail]> wrote:
> 
> I am approving the changes.
> 
> Yours,
> Daniel


> On Jan 8, 2024, at 12:04 PM, Karen Moore <[e-mail]> wrote:
> 
> Hi Michael, Ralf, and Éric*,
> 
> Thank you for your replies. We have updated our files accordingly and noted Ralf’s approval on the AUTH48 status page for this document.
> 
> *Eric, please review the addition of text to Section 2 and the suggested change to Section 10 and let us know if you approve. There is also a question from Michael (see #3). The changes are highlighted below, and you can view them in this diff file: https://www.rfc-editor.org/authors/rfc9526-auth48diff.htm.
> 
> 1) Section 2
> Original:
> DNS Resolver:  A resolver that performs a DNS resolution on the
>     Internet for the Public Homenet Zone.  The resolution is performed
>     by requesting the Public Authoritative Servers.  
> 
> Current:
> DNS Resolver:  A resolver that performs a DNS resolution on the
>     Internet for the Public Homenet Zone.  The resolution is performed
>     by requesting the Public Authoritative Servers.  While the
>     resolver does not necessarily perform DNSSEC resolutions, it is
>     expected that DNSSEC is enabled.
> 
> ...
> 2) Section 10
> [MR]: I wonder if Section 10 should use more bits in the prefix.
> 
> Old:
>   For example, if the ISP has assigned 2001:db8:f00d::/64 to the WAN
>   interface (by DHCPv6 or PPP and Router Advertisement (RA)), then the
>   HNA should originate Synchronization Channel updates from, for
>   example, 2001:db8:f00d::2.
> 
> New:
>   For example, if the ISP has assigned 2001:db8:f00d:1234::/64 to the WAN
>   interface (by DHCPv6 or PPP and Router Advertisement (RA)), then the
>   HNA should originate Synchronization Channel updates from, for
>   example, 2001:db8:f00d:1234::2.
> 
> ...
> 3) Michael pointed out that there is a “MUST NOT” in the Security Considerations (Section 14.1). Please confirm if this is correct or if an update is needed.
> 
> Current:
>   The DOI MUST NOT serve any Public Homenet Zone when it is not
>   confident that the HNA owns the Registered Homenet Domain.  Proof of
>   ownership is outside the scope of this document, and it is assumed
>   that such a phase has preceded the outsourcing of the zone.
> 
> 
> FILES (please refresh)
> 
> The updated XML file is here:
> https://www.rfc-editor.org/authors/rfc9526.xml
> 
> The updated output files are here:
> https://www.rfc-editor.org/authors/rfc9526.txt
> https://www.rfc-editor.org/authors/rfc9526.pdf
> https://www.rfc-editor.org/authors/rfc9526.html
> 
> This diff file shows all changes made during AUTH48:
> https://www.rfc-editor.org/authors/rfc9526-auth48diff.html
> 
> This diff file shows all changes made to date:
> https://www.rfc-editor.org/authors/rfc9526-diff.html
> 
> Please contact us with any further updates or with your approval of the document in its current form.  We will await approvals from Daniel, Michael, Ray, and Éric (AD) prior to moving forward in the publication process.
> 
> For the AUTH48 status of this document, please see:
> https://www.rfc-editor.org/auth48/rfc9526
> 
> Best regards,
> RFC Editor/kc
> 
> 
>> On Jan 7, 2024, at 3:51 AM, Ralf Weber <rweber=[e-mail]> wrote:
>> 
>> Moin!
>> 
>> On 19 Dec 2023, at 6:57, [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 am ok with the review and the changes proposed by Daniel and Michael.
>> 
>> I approve publication.
>> 
>> Sorry for the late reply that went under in the pre holiday preparations.
>> 
>> So long
>> -Ralf
>> ---
>> Ralf Weber
> 
> 
>> On Dec 23, 2023, at 7:41 AM, Michael Richardson <[e-mail]> wrote:
>> 
>> 
>> I have read the document from Dec.22 from top to bottom.
>> (So many diffs, I actually read the diff file, but that was the entire
>> document).
>> 
>> 1. I am happy with the result.
>> 2. I approve using: "2001:db8:1f15:62e:21c::/64”
>> 3. I wonder if section 10 should use more bits in the prefix (see below)
>> 4. Section 14.1 (Security Considerations) has a MUST, and I wonder about
>>  that.
>> 
>> 5. Appendix B, yes, source code, CDDL for the "hna-configuration", but no,
>> not for the example.
>> 
>> section 10:
>> OLD:
>> For example, if the ISP has assigned 2001:db8:f00d::/64 to the WAN
>> interface (by DHCPv6 or PPP and Router Advertisement (RA)), then the
>> HNA should originate Synchronization Channel updates from, for
>> example, 2001:db8:f00d::2.
>> 
>> NEW:
>> For example, if the ISP has assigned 2001:db8:f00d:1234::/64 to the WAN
>> interface (by DHCPv6 or PPP and Router Advertisement (RA)), then the
>> HNA should originate Synchronization Channel updates from, for
>> example, 2001:db8:f00d:1234::2.
>> 
>> 
>> --
>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>>          Sandelman Software Works Inc, Ottawa and Worldwide
>> 
> 
>> On Dec 22, 2023, at 11:25 AM, Karen Moore <[e-mail]> wrote:
>> 
>> Éric*,
>> 
>> Thank you for spotting the change to the sourcecode.  We have updated two instances of "2001:db8:1f15:62e:21c::/64” to "2001:db8:1f15:62e::/64” (Appendix B), and we will not make any changes to “Distribution Master”.
>> 
>> Authors, if you prefer to use Éric’s suggestion of "2001:db8:1f15:62e:21c::/80” instead, please let us know.
>> 
>> *Éric, please review the addition of text in Section 2, and let us know if you approve. The change is highlighted below, and you can view it in this diff file: https://www.rfc-editor.org/authors/rfc9526-auth48diff.htm.
>> 
>> Original:
>> DNS Resolver:  A resolver that performs a DNS resolution on the
>>     Internet for the Public Homenet Zone.  The resolution is performed
>>     by requesting the Public Authoritative Servers.  
>> 
>> Current:
>> DNS Resolver:  A resolver that performs a DNS resolution on the
>>     Internet for the Public Homenet Zone.  The resolution is performed
>>     by requesting the Public Authoritative Servers.  While the
>>     resolver does not necessarily perform DNSSEC resolutions, it is
>>     expected that DNSSEC is enabled.
>> 
>> 
>> FILES (please refresh):
>> 
>> The updated XML file is here:
>> https://www.rfc-editor.org/authors/rfc9526.xml
>> 
>> The updated output files are here:
>> https://www.rfc-editor.org/authors/rfc9526.txt
>> https://www.rfc-editor.org/authors/rfc9526.pdf
>> https://www.rfc-editor.org/authors/rfc9526.html
>> 
>> This diff file shows all changes made during AUTH48:
>> https://www.rfc-editor.org/authors/rfc9526-auth48diff.html
>> 
>> This diff file shows all changes made to date:
>> https://www.rfc-editor.org/authors/rfc9526-diff.html
>> 
>> 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/rfc9526
>> 
>> Thank you,
>> RFC Editor/kc
>> 
>> 
>>> On Dec 22, 2023, at 7:25 AM, Eric Vyncke (evyncke) <[e-mail]> wrote:
>>> 
>>> Karen and authors,
>>> 
>>> I should have spotted this before but 2001:db8:1f15:62e:21c::/64 is not correct IMHO, it should rather be 2001:db8:1f15:62e::/64,or 2001:db8:1f15:62e:21c::/80
>>> 
>>> -éric
>>> 
>>>> 7) We are wondering if the type for this sourcecode example should be set as "cddl” or left blank - please confirm.
>>>> 
>>>> <mglt>
>>>> I see the text as a json object, so I think cddl may not be appropriated and I would leave it blank unless Michael has another opinion on that. 
>>>> </mglt>
>>>> <sourcecode><![CDATA[
>>>> {
>>>> "registered_domain" : "n8d234f.r.example.net",
>>>> "dm"                : "2001:db8:1234:111:222::2",
>>>> "dm_transport"      : "DoT",
>>>> "dm_port"           : 4433,
>>>> "dm_acl"            : "2001:db8:1f15:62e:21c::/64"
>>>>                 or [ "2001:db8:1f15:62e:21c::/64", ... ]
>>>> "hna_auth_method"   : "certificate",
>>>> "hna_certificate"   : "-----BEGIN CERTIFICATE-----\nMIIDTjCCFGy..",
>>>> }
>>>> ]]></sourcecode>
>>> 
>> 
>> 
>>> On Dec 20, 2023, at 5:58 PM, Karen Moore <[e-mail]> wrote:
>>> 
>>> Hi Daniel,
>>> 
>>> Thank you for your replies. We have updated our files to reflect the change per #6 below. For #3, we believe you have confirmed that the current text is agreeable, so we did not make any further changes; if that is not the case, please let us know.  We will await word from Michael regarding if the sourcecode type should be “JSON” or left blank (per #7 below).
>>> 
>>> FILES (please refresh)
>>> 
>>> The updated XML file is here:
>>> https://www.rfc-editor.org/authors/rfc9526.xml
>>> 
>>> The updated output files are here:
>>> https://www.rfc-editor.org/authors/rfc9526.txt
>>> https://www.rfc-editor.org/authors/rfc9526.pdf
>>> https://www.rfc-editor.org/authors/rfc9526.html
>>> 
>>> This diff file shows all changes made during AUTH48:
>>> https://www.rfc-editor.org/authors/rfc9526-auth48diff.html
>>> 
>>> This diff file shows all changes made to date:
>>> https://www.rfc-editor.org/authors/rfc9526-diff.html
>>> 
>>> 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/rfc9526
>>> 
>>> Thank you!
>>> RFC Editor/kc
>>> 
>>>> On Dec 20, 2023, at 12:14 PM, Daniel Migault <[e-mail]> wrote:
>>>> 
>>>> Hi Karen, 
>>>> 
>>>> Thanks for the follow-up. Here are my response in line. There is one comment I would like a confirmation from MIchael. This is comment 7 in this mail, I interpret the sourcecode as a json object and as such do not believe that cddl is appropriate, but I might be wrong.
>>>> 
>>>> Yours, 
>>>> Daniel
>>>> 
>>>> ________________________________________
>>>> From: Karen Moore <[e-mail]>
>>>> Sent: Wednesday, December 20, 2023 2:55 PM
>>>> To: Daniel Migault; [e-mail]; [e-mail]; [e-mail]
>>>> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
>>>> Subject: Re: AUTH48: RFC-to-be 9526 <draft-ietf-homenet-front-end-naming-delegation-27> for your review
>>>> 
>>>> Dear Daniel,
>>>> 
>>>> Thank you for your review and reply.  We have updated our files accordingly, and the links to the diff files can be accessed further down in this email. Please see some notes and additional questions below.
>>>> 
>>>> 1) Please confirm if any additional keywords should be added or not.
>>>> <mglt>
>>>> I understand key words as those used to search the draft. These include the words in the title "Simple Provisioning of Public Names for Residential Networks". I think we can add DNS, Homenet, outsourcing, management, hosting.
>>>> </mglt>
>>>> 
>>>> 2) Note that for consistency, we updated “Homenet Resolver” to “Homenet DNS Resolver”.
>>>> <mglt>
>>>> I am fine with that.
>>>> </mglt>
>>>> 
>>>> 3) Note that we updated the text as shown below.  Please let us know if this is correct as is or if it should be updated as “therefore, they are represented as Homenet Zones in Figure 2” (i.e., should “Homenet Zone" be plural rather than singular?).
>>>> 
>>>>> Original:
>>>>> The ".local" as well as ".home.arpa" are explicitly not
>>>>> considered as Public Homenet zones and represented as a
>>>>> Homenet Zone in Figure 2.
>>>>> 
>>>>> Current:
>>>>> ".local" and ".home.arpa" are explicitly not
>>>>> considered Public Homenet Zones; therefore, they are
>>>>> represented as a Homenet Zone in Figure 2.
>>>> 
>>>> <mglt>
>>>> works for me.
>>>> </mglt>
>>>> 
>>>> 4) Regarding your question below, we were looking for an update to “build and server”. As far as “and” vs. “as well as”, either are correct in this context. If you would rather use “as well as”, we suggest the following. Please let us know your preference.
>>>> 
>>>> Perhaps:
>>>> It is worth noting that both the DM and HNA need to agree on a common
>>>> configuration in order to set up the Synchronization Channel as well as
>>>> build and serve a coherent Public Homenet Zone.
>>>> 
>>>> <mglt>
>>>> I am fine either ways with and or as well as. The current text is fine to me. 
>>>> </mglt>
>>>> 
>>>>> 13) <!--[rfced] The text "build and server" does not parse. Is the
>>>>> intended meaning "build and serve”?
>>>>> 
>>>>> Original:
>>>>> It is worth noting that both DM and HNA need to agree on a common
>>>>> configuration to set up the synchronization channel as well as to
>>>>> build and server a coherent Public Homenet Zone.
>>>>> 
>>>>> Perhaps:
>>>>> It is worth noting that both the DM and HNA need to agree on a common
>>>>> configuration in order to set up the Synchronization Channel and
>>>>> build and serve a coherent Public Homenet Zone.
>>>>> 
>>>>> <mglt>
>>>>> This is fine to me, but I do not understand why it did not parse. I suspect that "as well as" is not equivalent to "and", and if that is the case, I would be happy to understand the difference. This is for my own information. At least the reason I put as well as was that we wanted to say  to (set up the synchronization channel ) and ( build and serve) a coherent Public Homenet Zone where (build and serve) was factorized for the  a coherent Public Homenet Zone. If we had to expand this we wanted to say:  to set up the Synchronization Channel and
>>>>> build a coherent Public Homenet Zone and serve a coherent Public Homenet Zone.
>>>>> 
>>>>> Just to make it clear I am not trying to "discuss" the better wording but simply to understand it and avoid making the mistake in the future.
>>>>> </mglt>
>>>> 
>>>> 
>>>> ...
>>>> 5) Regarding your question below, we added “are” to the second sentence to make it a complete sentence (rather than a fragment), and then we added a comma and a conjunction (“and”) in order to connect the two complete sentences.
>>>> 
>>>>> Original:
>>>>> Suppose the HNA and the DM are using a single IP address and let
>>>>> designate by XX. YYYYY and ZZZZZ the various ports involved in
>>>>> the communications.
>>>>> 
>>>> 
>>>>> Perhaps:
>>>>> Suppose the HNA and the DM are using a single IP address designated
>>>>> by XX, and YYYYY and ZZZZZ are the various ports involved in
>>>>> the communications.
>>>>> 
>>>> 
>>>>> <mglt>
>>>>> That seems fine to me. Just for my information I am wondering if the coma after XX is used to indicate that XX i sthe IP address while YYYY and ZZZZ are the ports. If so, it might mean that in my previous comment "," is the replacement I should probably think of as opposed to use an equivalent of "and" such a "as well as".
>>>>> </mglt>
>>>> 
>>>> <mglt>
>>>> Thanks for the clarification. As I mentioned I am fine with the proposed text.
>>>> </mglt>
>>>> ...
>>>> 6) We are having trouble understanding the NEW text below. Does this phrasing capture the intended meaning about the update to RFC 9103?
>>>> 
>>>> Perhaps:
>>>> [RFC9103] makes no requirements or recommendations on any extended
>>>> key usage flags for zone transfers, and this document adopts the view
>>>> that none should be required. Note that once an update to [RFC9103] is
>>>> published, this document's normative reference to [RFC9103] will be
>>>> considered updated as well.
>>>> 
>>>> <mglt>
>>>> Sorry to be unclear. Yes that captures well th eintent.
>>>> </mglt>
>>>> 
>>>>> <mglt>
>>>>> The intention is to follow 9103 closely. The intended text was probably:
>>>>> 
>>>>> NEW:
>>>>> [RFC9103] makes no requirements or recommendations on any extended
>>>>> key usage flags for zone transfers, and this document adopts the view
>>>>> that none should be required and leave it up to [RFC9103] to get
>>>>> updated for this document's normative reference to be considered
>>>>> updated as well.
>>>> 
>>>> ...
>>>> 7) We are wondering if the type for this sourcecode example should be set as "cddl” or left blank - please confirm.
>>>> 
>>>> <mglt>
>>>> I see the text as a json object, so I think cddl may not be appropriated and I would leave it blank unless Michael has another opinion on that. 
>>>> </mglt>
>>>> <sourcecode><![CDATA[
>>>> {
>>>> "registered_domain" : "n8d234f.r.example.net",
>>>> "dm"                : "2001:db8:1234:111:222::2",
>>>> "dm_transport"      : "DoT",
>>>> "dm_port"           : 4433,
>>>> "dm_acl"            : "2001:db8:1f15:62e:21c::/64"
>>>>                or [ "2001:db8:1f15:62e:21c::/64", ... ]
>>>> "hna_auth_method"   : "certificate",
>>>> "hna_certificate"   : "-----BEGIN CERTIFICATE-----\nMIIDTjCCFGy..",
>>>> }
>>>> ]]></sourcecode>
>>>> 
>>>>> <mglt>
>>>>> I found one occurrence of source code and the type is cddl. I am wondering if there are any other sourcecode I am missing.
>>>>> </mglt>
>>>> 
>>>> ...
>>>> FILES
>>>> 
>>>> The updated XML file is here:
>>>> https://www.rfc-editor.org/authors/rfc9526.xml
>>>> 
>>>> The updated output files are here:
>>>> https://www.rfc-editor.org/authors/rfc9526.txt
>>>> https://www.rfc-editor.org/authors/rfc9526.pdf
>>>> https://www.rfc-editor.org/authors/rfc9526.html
>>>> 
>>>> This diff file shows all changes made during AUTH48:
>>>> https://www.rfc-editor.org/authors/rfc9526-auth48diff.html
>>>> 
>>>> This diff file shows all changes made to date:
>>>> https://www.rfc-editor.org/authors/rfc9526-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/rfc9526
>>>> 
>>>> Thank you,
>>>> RFC Editor/kc
>>>> 
>>>> 
>>>>> On Dec 19, 2023, at 7:54 AM, Daniel Migault <daniel.migault=[e-mail]> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> Thank you for the complete revision. Please find my response inline. Feel also free to let me know if any additional information is needed.
>>>>> 
>>>>> Yours,
>>>>> Daniel
>>>>> 
>>>>> 
>>>>> ________________________________________
>>>>> From: [e-mail] <[e-mail]>
>>>>> Sent: Tuesday, December 19, 2023 12:57 AM
>>>>> To: Daniel Migault; [e-mail]; [e-mail]; [e-mail]
>>>>> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
>>>>> Subject: Re: AUTH48: RFC-to-be 9526 <draft-ietf-homenet-front-end-naming-delegation-27> 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] We updated the short title that appears in the header
>>>>> of the PDF as follows. Please let us know if you prefer otherwise.
>>>>> 
>>>>> Original:
>>>>> public-names
>>>>> 
>>>>> Current:
>>>>> Public Names for Residential Networks
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> This is fine to me.
>>>>> </mglt>
>>>>> 
>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
>>>>> the title) for use on https://www.rfc-editor.org/search. -->
>>>>> 
>>>>> 
>>>>> 3) <!--[rfced] In the following, do "primary" and "secondary" refer to
>>>>> servers?  If so, for clarity, may we add "server" after both
>>>>> "primary" and "secondary" (since this is when the terms are
>>>>> introduced) as shown below?
>>>>> 
>>>>> Original:
>>>>> The Synchronization Channel is a zone transfer, with the HNA
>>>>> configured as a primary, and the Distribution Manager configured as a
>>>>> secondary.
>>>>> 
>>>>> Perhaps:
>>>>> The Synchronization Channel is a zone transfer, with the HNA
>>>>> configured as a primary server and the Distribution Manager
>>>>> configured as a secondary server.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> This is fine to me.
>>>>> </mglt>
>>>>> 
>>>>> 4) <!--[rfced] Introduction. For the descriptions of each section in the
>>>>> document, we notice that Section 4 is not mentioned until the
>>>>> last paragraph. Is this intentional, or should a brief summary of
>>>>> Section 4 be included after the mention of Section 3?
>>>>> 
>>>>> Original:
>>>>> Section 2 defines the terminology. Section 3 presents the
>>>>> general problem of publishing names and IP addresses.
>>>>> 
>>>>> Section 5 provides an architectural view of the HNA, DM and DOI
>>>>> as well as their different communication channels (Control Channel,
>>>>> Synchronization Channel, DM Distribution Channel) respectively
>>>>> described in Section 6, Section 7 and Section 8.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> This is not intentional. Maybe we could add the following sentence.
>>>>> 
>>>>> Section 4 briefly describes some potential envisioned deployment scenarios.
>>>>> 
>>>>> </mglt>
>>>>> 
>>>>> 5) <!--[rfced] Rather than "the (set of) server(s)", we suggest writing clearly
>>>>> "the server or set of servers" or "the server(s)". Does either option below
>>>>> convey your intended meaning?
>>>>> 
>>>>> Also, please clarify "and which"; does the DM distribute the information
>>>>> to the Public Authoritative Servers?
>>>>> 
>>>>> Original:
>>>>> Distribution Manager (DM):  is the (set of) server(s) to which the HNA
>>>>>  synchronizes the Public Homenet Zone, and which then distributes the
>>>>>  relevant information to the Public Authoritative Servers.
>>>>> 
>>>>> Option A:
>>>>> Distribution Manager (DM):  The server (or set of servers) that
>>>>>  the HNA uses to synchronize the Public Homenet Zone and that then
>>>>>  distributes the relevant information to the Public Authoritative
>>>>>  Servers.
>>>>> 
>>>>> Option B:
>>>>> Distribution Manager (DM):  The server (or set of servers) that
>>>>>  the HNA synchronizes the Public Homenet Zone to and that
>>>>>  then distributes the relevant information to the Public
>>>>>  Authoritative Servers.
>>>>> 
>>>>> [For B, ending the phrase with a preposition is in service to the goal
>>>>> of making the meaning clear.]
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> option B seems the preferred alternative.
>>>>> </mglt>
>>>>> 
>>>>> 6) <!--[rfced] FYI, this parenthetical shorthand "DNS(SEC) Resolver",
>>>>> which presumably means "DNS or DNSSEC Resolver", has not been used in RFCs.
>>>>> Would it be sufficient to use one term throughout the document and
>>>>> add a statement for the reader about its usage? For example:
>>>>> 
>>>>> In this document, when "DNS Resolver" is used, it refers to "DNS
>>>>> or DNSSEC Resolver".
>>>>> 
>>>>> <mglt>
>>>>> That seems fine to me. We though need to remain coherent with the Terminology section that defines the DNS(SEC) Resolver. I am fine updating the Terminology section as well.
>>>>> 
>>>>> I propose:
>>>>> 
>>>>> OLD:
>>>>> DNS(SEC) Resolver: a resolver that performs a DNS resolution on the Internet for the Public Homenet Zone.
>>>>> The resolution is performed requesting the Public Authoritative Servers.
>>>>> 
>>>>> NEW:
>>>>> DNS Resolver: a resolver that performs a DNS resolution on the Internet for the Public Homenet Zone.
>>>>> The resolution is performed requesting the Public Authoritative Servers. While the resolver does not necessarily performs DNSSEC resolutions, it is expected that DNSSEC is enabled.
>>>>> 
>>>>> 
>>>>> </mglt>
>>>>> 
>>>>> On a related note, in Appendix B, may the one instance of
>>>>> "DNS(SEC) resolution" be replaced  as follows? To summarize,
>>>>> using parentheses for a plural alternative is acceptable,
>>>>> but it is not desired for a term's alternative.
>>>>> 
>>>>> Original:
>>>>>  ... indicates an IP address or the IP addresses returned by the
>>>>>  DNS(SEC) resolution when dm indicates a FQDN.
>>>>> 
>>>>> Perhaps:
>>>>>  ... indicates the IP address(es) returned by the
>>>>>  DNS or DNSSEC resolution when dm indicates a FQDN.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> That seems fine to me.
>>>>> </mglt>
>>>>> 
>>>>> 7) <!--[rfced] We do not see mention of "IPv6" in RFC 3787. Is this
>>>>> reference correct, or is an update to the reference or text
>>>>> needed?
>>>>> 
>>>>> Original:
>>>>> A device or service SHOULD have Global Unicast Addresses (GUA)
>>>>> (IPv6 [RFC3787] or IPv4), but MAY also have Unique Local IPv6
>>>>> Addresses (ULA) [RFC4193], IPv6-Link-Local addresses[RFC4291]
>>>>> [RFC7404], IPv4-Link-Local Addresses [RFC3927] (LLA), and
>>>>> finally, private IPv4  addresses [RFC1918].
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> Thanks for catching this error. The RFC is 3587 and not 3787.
>>>>> 
>>>>> OLD:
>>>>> A device or service SHOULD have Global Unicast Addresses (GUA)
>>>>> (IPv6 [RFC3787] or IPv4), but MAY also have Unique Local IPv6
>>>>> Addresses (ULA) [RFC4193], IPv6-Link-Local addresses[RFC4291]
>>>>> [RFC7404], IPv4-Link-Local Addresses [RFC3927] (LLA), and
>>>>> finally, private IPv4  addresses [RFC1918].
>>>>> 
>>>>> NEW:
>>>>> A device or service SHOULD have Global Unicast Addresses (GUA)
>>>>> (IPv6 [RFC3587] or IPv4), but MAY also have Unique Local IPv6
>>>>> Addresses (ULA) [RFC4193], IPv6-Link-Local addresses[RFC4291]
>>>>> [RFC7404], IPv4-Link-Local Addresses [RFC3927] (LLA), and
>>>>> finally, private IPv4  addresses [RFC1918].
>>>>> 
>>>>> </mglt>
>>>>> 
>>>>> 8) <!--[rfced] May "Web GUI" be updated to "web-based GUIs",
>>>>> or does it refer to something else?
>>>>> 
>>>>> Original:
>>>>> The HNA may implement such interactions using Web GUI or
>>>>> specific mobile applications.
>>>>> 
>>>>> Perhaps:
>>>>> The HNA may implement such interactions using Web-based GUIs
>>>>> or specific mobile applications.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> This seems fine to me.
>>>>> </mglt>
>>>>> 
>>>>> 
>>>>> 9) <!--[rfced] In the following, "should be necessary" is
>>>>> confusing. Should this be "are necessary" instead?
>>>>> 
>>>>> Original:
>>>>> Normally the keys should be necessary and sufficient to
>>>>> proceed to the authentication.
>>>>> 
>>>>> Perhaps:
>>>>> Normally, the keys are necessary and sufficient to
>>>>> proceed to the authentication.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> I think so.
>>>>> </mglt>
>>>>> 
>>>>> 10) <!--[rfced] Please clarify "such as putting" in the following
>>>>> sentence. Could "such as providing" be used instead?
>>>>> (The preceding sentence is included for context.)
>>>>> 
>>>>> Original:
>>>>> ACME [RFC8555]
>>>>> is one protocol that would allow an owner of an existing domain
>>>>> name to prove their ownership (but requires they have DNS already
>>>>> setup!)  There are other ways such as putting a DOI generated TXT
>>>>> record, or web site contents, as championed by entities like
>>>>> Google's Sitemaster and Postmaster protocols.
>>>>> 
>>>>> Perhaps:
>>>>> Automatic Certificate Management Environment (ACME) [RFC8555]
>>>>> is one protocol that would allow an owner of an existing domain
>>>>> name to prove their ownership (but it requires that they have DNS
>>>>> already set up!). There are other ways to establish proof such as
>>>>> providing a DOI-generated TXT record, or web site contents, as
>>>>> championed by entities like Google's Sitemaster and Postmaster
>>>>> protocols.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> I think this works to me.
>>>>> </mglt>
>>>>> 
>>>>> 11) <!-- [rfced] Please review whether any of the notes in this document
>>>>> should be in the <aside> element. It is defined as "a container for
>>>>> content that is semantically less important or tangential to the
>>>>> content that surrounds it" (https://authors.ietf.org/rfcxml-vocabulary#aside).
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> I have never used the aside document. That said, the document has been undergo multiple restructurings to reach a consensus between what people believed as important and less important - in which case the less important content has been placed in the appendix. I prefer not to change anything of this kind at that point, put that is good to know there is a special mark for that.
>>>>> </mglt>
>>>>> 
>>>>> 12) <!--[rfced] Please clarify this sentence. Specifically:
>>>>> - We notice that ".local" is not included in Figure 2; is an
>>>>> update needed to Figure 2 or the text?
>>>>> - Are ".local" and ".home.arpa" referred to as domain names or otherwise?
>>>>> - Was "are not considered ... and not represented" intended?
>>>>> If so, then we suggest adding a second "not".
>>>>> 
>>>>> <mglt>
>>>>> I think the reason for not representing .local in the figure is that it is used but should not be used and instead  ".home.arpa" should be used.
>>>>> </mglt>
>>>>> 
>>>>> Original:
>>>>> The ".local" as well as ".home.arpa" are explicitly not
>>>>> considered as Public Homenet zones and represented as a
>>>>> Homenet Zone in Figure 2.
>>>>> 
>>>>> Perhaps:
>>>>> A) ".local" and ".home.arpa" are explicitly not
>>>>> considered Public Homenet Zones; therefore, they are
>>>>> represented as a Homenet Zone in Figure 2.
>>>>> or
>>>>> 
>>>>> B) The ".local" and ".home.arpa" domain names are explicitly not
>>>>> considered Public Homenet Zones; therefore, they are
>>>>> represented as Homenet Zones in Figure 2.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> I prefer option A as .local and home.arpa as, in my opinion and in our case, these are not really domain names but the zone (maybe apex) or something like that but I am not so sure.
>>>>> </mglt>
>>>>> 
>>>>> 13) <!--[rfced] The text "build and server" does not parse. Is the
>>>>> intended meaning "build and serve"?
>>>>> 
>>>>> Original:
>>>>> It is worth noting that both DM and HNA need to agree on a common
>>>>> configuration to set up the synchronization channel as well as to
>>>>> build and server a coherent Public Homenet Zone.
>>>>> 
>>>>> Perhaps:
>>>>> It is worth noting that both the DM and HNA need to agree on a common
>>>>> configuration in order to set up the Synchronization Channel and
>>>>> build and serve a coherent Public Homenet Zone.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> This is fine to me, but I do not understand why it did not parse. I suspect that "as well as" is not equivalent to "and", and if that is the case, I would be happy to understand the difference. This is for my own information. At least the reason I put as well as was that we wanted to say  to (set up the synchronization channel ) and ( build and serve) a coherent Public Homenet Zone where (build and serve) was factorized for the  a coherent Public Homenet Zone. If we had to expand this we wanted to say:  to set up the Synchronization Channel and
>>>>> build a coherent Public Homenet Zone and serve a coherent Public Homenet Zone.
>>>>> 
>>>>> Just to make it clear I am not trying to "discuss" the better wording but simply to understand it and avoid making the mistake in the future.
>>>>> </mglt>
>>>>> 
>>>>> 14) <!--[rfced] Does the DM serve the Control and Synchronization Channels
>>>>> on a single port by using a single transport protocol? If so,
>>>>> please let us know how we may rephrase this sentence for clarity.
>>>>> 
>>>>> Original:
>>>>> *  the DM serves both the Control Channel and Synchronization Channel
>>>>>  on a single IP address, single port and using a single transport
>>>>>  protocol.
>>>>> 
>>>>> Perhaps:
>>>>> *  the DM serves both the Control Channel and Synchronization Channel
>>>>>  on a single IP address, on a single port, and by using a single
>>>>>  transport protocol.
>>>>> -->
>>>>> <mglt>
>>>>> That is fine to me.
>>>>> </mglt>
>>>>> 
>>>>> 15) <!--[rfced] May we streamline the following section titles by updating
>>>>> them as shown below? Please review.
>>>>> 
>>>>> Original:
>>>>> 6.1.  Information to Build the Public Homenet Zone
>>>>> 6.2.  Information to build the DNSSEC chain of trust
>>>>> 6.3.  Information to set up the Synchronization Channel
>>>>> [...]
>>>>> 6.5.  Messages Exchange Description
>>>>> [...]
>>>>> 6.5.4.  HNA instructing deleting the delegation
>>>>> [...]
>>>>> A.1.  Homenet Public Zone
>>>>> 
>>>>> Perhaps:
>>>>> 6.1.  Building the Public Homenet Zone
>>>>> 6.2.  Building the DNSSEC Chain of Trust
>>>>> 6.3.  Setting Up the Synchronization Channel
>>>>> [...]
>>>>> 6.5.  Message Exchange Description
>>>>> [...]
>>>>> 6.5.4.  Initiating Deletion of the Delegation
>>>>> [...]
>>>>> A.1.  Public Homenet Zone
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> This works fine to me. Thank you fo rthe suggestions.
>>>>> 
>>>>> </mglt>
>>>>> 
>>>>> 16) <!--[rfced] The following sentence does not parse. The text states
>>>>> that the HNA MUST not exceed the SOA's values to those provided
>>>>> by the AXFR response; please clarify what "to those provided by
>>>>> the AXFR response" means. Also, should "MUST not" be updated as
>>>>> "MUST NOT"?
>>>>> 
>>>>> Original:
>>>>> The HNA MUST not exceed the values of NAME, REFRESH, RETRY, EXPIRE and
>>>>> MINIMUM of the SOA to those provided by the AXFR response.
>>>>> 
>>>>> Perhaps:
>>>>> The HNA MUST NOT exceed the values of NAME, REFRESH, RETRY, EXPIRE and
>>>>> MINIMUM of the SOA provided by the AXFR response.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> 
>>>>> It seems fine to me.
>>>>> </mglt>
>>>>> 
>>>>> 17) <!--[rfced] Please clarify "proceed to the configuration". Is the intended
>>>>> meaning about proceeding to "use", "set", or "identify" the configuration?
>>>>> (FYI, there is a similar question about the abstract of RFC-to-be 9527.)
>>>>> 
>>>>> Original:
>>>>> A REFUSED error is returned when the DM refuses to proceed to the
>>>>> configuration and the requested action.
>>>>> 
>>>>> Perhaps:
>>>>> A REFUSED error is returned when the DM refuses to use the
>>>>> configuration or perform the requested action.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> I am fine with the proposed alternative, but I might propose th efollowing one:
>>>>> 
>>>>> Perhaps:
>>>>> A REFUSED error is returned when the DM refuses the
>>>>> configuration or performing the requested action.
>>>>> 
>>>>> 
>>>>> </mglt>
>>>>> 
>>>>> 18) <!--[rfced] FYI, we replaced "To instruct to delete" with "To initiate
>>>>> the deletion of". Please let us know if you prefer otherwise.
>>>>> 
>>>>> Original:
>>>>> To instruct to delete the delegation the HNA sends a DNS
>>>>> UPDATE Delete message.
>>>>> 
>>>>> Current:
>>>>> To initiate the deletion of the delegation, the HNA sends
>>>>> a DNS UPDATE Delete message.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> This is fine to me. The reason I like "instruct" is that is make it clear it sends an message or an order to perform the deletion, but if that is not an appropriate use of instruct, I agree with the change.
>>>>> </mglt>
>>>>> 
>>>>> 19) <!--[rfced] Would it be correct to say that the delete instruction is
>>>>> "initiated by setting" rather than "set by setting" as shown
>>>>> below? Also, should "Class" be "CLASS" to match use in RFC 2136?
>>>>> 
>>>>> Original:
>>>>> As indicated by [RFC2136] Section 2.5.2 the delete instruction is
>>>>> set by setting the TTL to 0, the Class to ANY, the RDLENGTH to 0
>>>>> and the RDATA MUST be empty.
>>>>> 
>>>>> Perhaps:
>>>>> As indicated by [RFC2136], Section 2.5.2, the delete instruction is
>>>>> initiated by setting TTL to 0, CLASS to ANY, and RDLENGTH
>>>>> to 0, and RDATA MUST be empty.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> That sounds good to me. I think we can removed "the" because capital designates a specific and well defined field.
>>>>> </mglt>
>>>>> 
>>>>> 20) <!--[rfced] There is text missing after "ZZZZZ" - is it perhaps "are"?
>>>>> Also, may we combine these two sentences for clarity? Please
>>>>> review.
>>>>> 
>>>>> Original:
>>>>> Suppose the HNA and the DM are using a single IP address and let
>>>>> designate by XX. YYYYY and ZZZZZ the various ports involved in
>>>>> the communications.
>>>>> 
>>>>> Perhaps:
>>>>> Suppose the HNA and the DM are using a single IP address designated
>>>>> by XX, and YYYYY and ZZZZZ are the various ports involved in
>>>>> the communications.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> That seems fine to me. Just for my information I am wondering if the coma after XX is used to indicate that XX i sthe IP address while YYYY and ZZZZ are the ports. If so, it might mean that in my previous comment "," is the replacement I should probably think of as opposed to use an equivalent of "and" such a "as well as".
>>>>> </mglt>
>>>>> 
>>>>> 21) <!--[rfced] Please clarify these two sentences, specifically:
>>>>> - Does "working as a client" refer to the HNA in the first sentence,
>>>>> and the DM in the second sentence?
>>>>> <mglt>
>>>>> yes.
>>>>> </mglt>
>>>>> 
>>>>> - Is the phrase "toward a service" necessary?
>>>>> Please review whether an option below conveys the intended meaning.
>>>>> 
>>>>> <mglt>
>>>>> In my opinion, this is useful to clarify that we have two channels.
>>>>> </mglt>
>>>>> 
>>>>> Original:
>>>>> The Control Channel is between the HNA working as a client using port
>>>>> number YYYYY (an ephemeral also commonly designated as high range
>>>>> port) toward a service provided by the DM at port 853, when using
>>>>> DoT.
>>>>> 
>>>>> On the other hand, the Synchronization Channel is set between the DM
>>>>> working as a client using port ZZZZZ (another ephemeral port) toward
>>>>> a service provided by the HNA at port 853.
>>>>> 
>>>>> Option A:
>>>>> The Control Channel is between the HNA and a service provided by the DM at
>>>>> port 853 when using DoT. The HNA is working as a client using port number
>>>>> YYYYY (an ephemeral also commonly designated as a high range port).
>>>>> 
>>>>> On the other hand, the Synchronization Channel is between the DM and a
>>>>> service provided by the HNA at port 853.  The DM is working as a client
>>>>> using port ZZZZZ (another ephemeral port).
>>>>> 
>>>>> Option B:
>>>>> The Control Channel is between
>>>>> * the HNA working as a client using port number YYYYY (an ephemeral
>>>>>   also commonly designated as high range port) and
>>>>> * a service provided by the DM at port 853, when using DoT.
>>>>> 
>>>>> On the other hand, the Synchronization Channel is between
>>>>> * the DM working as a client using port ZZZZZ (another ephemeral
>>>>>   port) and
>>>>> * a service provided by the HNA at port 853.
>>>>> -->
>>>>> <mglt>
>>>>> Option B has the merit to be explicit and clear. I am fine with this alternative.
>>>>> </mglt>
>>>>> 
>>>>> 22) <!--[rfced] Please clarify the second sentence below (that begins with
>>>>> "and leave it up to") as we are having trouble understanding the
>>>>> intended meaning about the normative reference. (The preceding
>>>>> sentence is included for context.)
>>>>> 
>>>>> Original:
>>>>> [RFC9103] makes no requirements or recommendations on any extended
>>>>> key usage flags for zone transfers, and this document adopts the view
>>>>> that none should be required.  and leave it up to [RFC9103] to get
>>>>> updated for this document's normative reference to be considered
>>>>> updated as well.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> The intention is to follow 9103 closely. The intended text was probably:
>>>>> 
>>>>> NEW:
>>>>> [RFC9103] makes no requirements or recommendations on any extended
>>>>> key usage flags for zone transfers, and this document adopts the view
>>>>> that none should be required and leave it up to [RFC9103] to get
>>>>> updated for this document's normative reference to be considered
>>>>> updated as well.
>>>>> 
>>>>> </mglt>
>>>>> 
>>>>> 23) <!--[rfced] The following sentence does not parse. Please let us know
>>>>> if the suggested text is accurate or if you prefer otherwise.
>>>>> 
>>>>> Original:
>>>>> An ISP that has delegated 2001:db8:aeae::/56 to the HNA via
>>>>> DHCPv6-PD, then HNA should originate Synchronization Channel updates
>>>>> an IP within that subnet, such as 2001:db8:aeae:1::2.
>>>>> 
>>>>> Perhaps:
>>>>> If an ISP has delegated 2001:db8:aeae::/56 to the HNA via
>>>>> DHCPv6-PD, then the HNA should originate Synchronization Channel
>>>>> updates to an IP address within that subnet, such as 2001:db8:aeae:1::2.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> This sounds fine to me.
>>>>> </mglt>
>>>>> 
>>>>> 24) <!--[rfced] Should it be "to multiple ISPs" or "by multiple ISPs"
>>>>> in the following sentence?
>>>>> 
>>>>> Original:
>>>>> Note that for home networks connected to by multiple ISPs, each ISP
>>>>> provides only the DOI of the reverse zones associated with the
>>>>> delegated prefix.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> I am fine with both alternatives. I understand "to" meaning we are connected to the ISP network while "by" put the ISP in the shoes of a service provider.
>>>>> </mglt>
>>>>> 
>>>>> 25) <!--[rfced] Please confirm what is being performed: is it perhaps the
>>>>> reverse zone update or function?
>>>>> 
>>>>> Original:
>>>>> More specifically, the reverse zone associated with prefix 1 will not
>>>>> be possible to be performs by the HNA using an IP address that
>>>>> belongs to prefix 2.
>>>>> 
>>>>> Perhaps:
>>>>> More specifically, the reverse zone update associated with prefix 1
>>>>> cannot be performed by the HNA using an IP address that
>>>>> belongs to prefix 2.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> This is fine to me.
>>>>> </mglt>
>>>>> 
>>>>> 26) <!--[rfced] Please clarify what is used in RFC 9103 - is it
>>>>> a specific mechanism or guidance?
>>>>> 
>>>>> Original:
>>>>> Even if [RFC9103] is used by the DNS Outsourcing Infrastructure,
>>>>> it may still leak the existence of the zone through Notifies.
>>>>> 
>>>>> Perhaps:
>>>>> Even if DNS zone transfer over TLS [RFC9103] is used by the DOI,
>>>>> it may still leak the existence of the zone through Notifies.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> It is fine. What we meant is that 9103 does not necessarily protects the Notify. 9103 makes it optional.
>>>>> </mglt>
>>>>> 
>>>>> 27) <!--[rfced] Please confirm that RFC 6092 is the correct reference here.
>>>>> RFC 7084 mentions the "outgoing interface", but RFC 6092 does not
>>>>> contain the word "outgoing".
>>>>> 
>>>>> Original:
>>>>> [RFC7084] mandates that the outgoing-only policy [RFC6092] be
>>>>> available, and in many cases it is configured by default.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> This sounds to me the correct reference. They use the term "to the Internet", but I do not see any confusion.
>>>>> </mglt>
>>>>> 
>>>>> 28) <!-- [rfced] FYI, we have used the <sup> element for superscript
>>>>> in this document. Please review how it looks in Section 14.3,
>>>>> for example, "2^32" (in text).
>>>>> 
>>>>> Note: In the HTML and PDF, it appears as superscript. In the text
>>>>> output, <sup> generates a^b.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> This is correct.
>>>>> </mglt>
>>>>> 
>>>>> 29) <!-- [rfced] Would you like to use the <sub> element for subscript
>>>>> anywhere in this document? For example, IA_PD.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> IA_PD is a name that does not includes any subscript. I do not see any subscript being used in the document.
>>>>> </mglt>
>>>>> 
>>>>> 30) <!-- [rfced] Please review the "type" attribute of each sourcecode element
>>>>> in the XML file to ensure correctness. If the current list of preferred
>>>>> values for "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt)
>>>>> does not contain an applicable type, then feel free to let us know.
>>>>> Also, it is acceptable to leave the "type" attribute not set.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> I found one occurrence of source code and the type is cddl. I am wondering if there are any other sourcecode I am missing.
>>>>> </mglt>
>>>>> 
>>>>> <sourcecode type="cddl"><![CDATA[
>>>>> hna-configuration = {
>>>>> "registered_domain" : tstr,
>>>>> "dm"                : tstr,
>>>>> ? "dm_transport" : "DoT"
>>>>> ? "dm_port"        : uint,
>>>>> ? "dm_acl"         : hna-acl / [ +hna-acl ]
>>>>> ? "hna_auth_method": hna-auth-method
>>>>> ? "hna_certificate": tstr
>>>>> }
>>>>> 
>>>>> hna-acl          = tstr
>>>>> hna-auth-method  /= "certificate"
>>>>> ]]></sourcecode>
>>>>>  <t>For example:</t>
>>>>>  <!-- NOT actually json, as it is two examples merged -->
>>>>> 
>>>>> 
>>>>> 31) <!--[rfced] FYI, two characters were removed from this sourcecode
>>>>> element in order to fit within the 69-character limit for sourcecode.
>>>>> Specifically, for "hna_certificate", "...." was changed to ".."
>>>>> Please let us know if this change is acceptable..
>>>>> -->
>>>>> <mglt>
>>>>> I think the replacement is not fron the sourcecode but from a text that represent a json object. This is fine.
>>>>> </mglt>
>>>>> 
>>>>> 32) <!--[rfced] Please consider adding what part of RFC 9527 is the appropriate
>>>>> interface.
>>>>> 
>>>>> Current:
>>>>> For reverse zones, the relationship is always with the upstream ISP
>>>>> (although there may be more than one), so [RFC9527] is always the
>>>>> appropriate interface.
>>>>> 
>>>>> Perhaps:
>>>>> For reverse zones, the relationship is always with the upstream ISP
>>>>> (although there may be more than one), so DHCPv6 with options for the
>>>>> HNA [RFC9527] is always the appropriate interface.
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> I think we wanted to say that [RFC9527] applies. I woudl suggest to say:
>>>>> 
>>>>> Current:
>>>>> For reverse zones, the relationship is always with the upstream ISP
>>>>> (although there may be more than one), so [RFC9527] is always the
>>>>> appropriate interface.
>>>>> 
>>>>> NEW:
>>>>> For reverse zones, the relationship is always with the upstream ISP
>>>>> (although there may be more than one), so [RFC9527] always applies.
>>>>> 
>>>>> </mglt>
>>>>> 
>>>>> 
>>>>> 33) <!-- [rfced] Terminology and Abbreviations
>>>>> 
>>>>> 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. Note that the number
>>>>> of instances is included in parentheses for reference.
>>>>> 
>>>>> DNS(SEC) Resolver (3) vs. DNS(SEC) resolver (1) vs. DNSSEC resolver (2)
>>>>> 
>>>>> <mglt>
>>>>> according to comment 6, this should be replaced as DNS Resolver
>>>>> </mglt>
>>>>> 
>>>>> Homenet Resolver (1) vs. Homenet resolver (1)
>>>>> 
>>>>> <mglt>
>>>>> In my opinion this should be Homenet DNS Resolver or Homenet Resolver to remain coherent with comment 6. The Terminology section needs to be updated as well.
>>>>> 
>>>>> OLD:
>>>>> Homenet DNS(SEC) Resolver:
>>>>> a resolver that performs a DNS(SEC) resolution on the home network for the Public Homenet Zone.
>>>>> The resolution is performed requesting the Homenet Authoritative Servers.</t>
>>>>> 
>>>>> NEW:
>>>>> Homenet Resolver:
>>>>> a resolver that performs a DNS(SEC) resolution on the home network for the Public Homenet Zone.
>>>>> The resolution is performed requesting the Homenet Authoritative Servers.</t>
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Hidden Primary Server (3) vs. hidden primary server (1)
>>>>> 
>>>>> Hidden Primary (2) vs. hidden primary (5)
>>>>> [Note: should "server" be added to any of these instances for
>>>>>  consistency?]
>>>>> <mglt>
>>>>> maybe hidden primary server is the appropriate change.
>>>>> </mglt>
>>>>> 
>>>>> OAUTH2 (2)
>>>>> [Note: should this be "OAuth 2.0" per RFC 6749?]
>>>>> 
>>>>> <mglt>
>>>>> yes that is correct.
>>>>> </mglt>
>>>>> 
>>>>> b) We updated the text to reflect the latter forms for consistency.
>>>>> Please let us know if any further updates are needed.
>>>>> 
>>>>> control channel -> Control Channel (2)
>>>>> DNS notifies -> DNS Notifies (2)
>>>>> DNS Update -> DNS update (1) (per RFC 3007)
>>>>> Home network -> home network (1)
>>>>> homenet -> Homenet (3)
>>>>> [Note: there are 3 lowercase instances that are used in general;
>>>>> please let us know if any further changes are needed]
>>>>> <mglt>This is fine.</mglt>
>>>>> Parameter -> parameter (1)
>>>>> Prefix Delegation -> prefix delegation (1)
>>>>> prerequisite -> Prerequisite (1)
>>>>> Public Homenet zone -> Public Homenet Zone (2)
>>>>> Registrar -> registrar (2) (note: "DNS Registrar" is capitalized)
>>>>> RRSet -> RRset (1)
>>>>> SOA Query -> SOA query (1) (per RFC 9103)
>>>>> synchronization channel -> Synchronization Channel (6)
>>>>> User Interface -> user interface (1) (per RFC 8375)
>>>>> X509 -> X.509 (2) (RFC 9525)
>>>>> 
>>>>> <mglt>Thanks for fixing this.</mglt>
>>>>> 
>>>>> c) FYI - We have added expansions for abbreviations upon first use
>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
>>>>> expansion in the document carefully to ensure correctness.
>>>>> -->
>>>>> 
>>>>> <mglt>There is nothing I noticed wrong in reviwing the diff.
>>>>> </mglt>
>>>>> 
>>>>> 34) <!-- [rfced] Please review the "Inclusive Language" portion of the online
>>>>> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>>>>> and let us know if any changes are needed.
>>>>> 
>>>>> For example, please consider whether the following should be updated
>>>>> (or removed since it is included for "historically known as"):
>>>>> "Distribution Master".
>>>>> -->
>>>>> 
>>>>> <mglt>
>>>>> I believe this is useful to keep it as everyone calls it this way. It is mentioned as history to comply with the inclusive language policy.
>>>>> </mglt>
>>>>> 
>>>>> Thank you.
>>>>> 
>>>>> RFC Editor/kc/ar
>>>>> 
>>>>> 
>>>>> On Dec 18, 2023, [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/).
>>>>> 
>>>>> You and you coauthors are responsible for engaging other parties
>>>>> (e.g., Contributors or Working Group) as necessary before providing
>>>>> your approval.
>>>>> 
>>>>> Planning your review
>>>>> ---------------------
>>>>> 
>>>>> Please review the following aspects of your document:
>>>>> 
>>>>> *  RFC Editor questions
>>>>> 
>>>>> Please review and resolve any questions raised by the RFC Editor
>>>>> that have been included in the XML file as comments marked as
>>>>> follows:
>>>>> 
>>>>> <!-- [rfced] ... -->
>>>>> 
>>>>> These questions will also be sent in a subsequent email.
>>>>> 
>>>>> *  Changes submitted by coauthors
>>>>> 
>>>>> Please ensure that you review any changes submitted by your
>>>>> coauthors.  We assume that if you do not speak up that you
>>>>> agree to changes submitted by your coauthors.
>>>>> 
>>>>> *  Content
>>>>> 
>>>>> Please review the full content of the document, as this cannot
>>>>> change once the RFC is published.  Please pay particular attention to:
>>>>> - IANA considerations updates (if applicable)
>>>>> - contact information
>>>>> - references
>>>>> 
>>>>> *  Copyright notices and legends
>>>>> 
>>>>> Please review the copyright notice and legends as defined in
>>>>> RFC 5378 and the Trust Legal Provisions
>>>>> (TLP - https://trustee.ietf.org/license-info/).
>>>>> 
>>>>> *  Semantic markup
>>>>> 
>>>>> Please review the markup in the XML file to ensure that elements of
>>>>> content are correctly tagged.  For example, ensure that <sourcecode>
>>>>> and <artwork> are set correctly.  See details at
>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>>>> 
>>>>> *  Formatted output
>>>>> 
>>>>> Please review the PDF, HTML, and TXT files to ensure that the
>>>>> formatted output, as generated from the markup in the XML file, is
>>>>> reasonable.  Please note that the TXT will have formatting
>>>>> limitations compared to the PDF and HTML.
>>>>> 
>>>>> 
>>>>> Submitting changes
>>>>> ------------------
>>>>> 
>>>>> To submit changes, please reply to this email using 'REPLY ALL' as all
>>>>> the parties CCed on this message need to see your changes. The parties
>>>>> include:
>>>>> 
>>>>> *  your coauthors
>>>>> 
>>>>> *  [e-mail] (the RPC team)
>>>>> 
>>>>> *  other document participants, depending on the stream (e.g.,
>>>>> IETF Stream participants are your working group chairs, the
>>>>> responsible ADs, and the document shepherd).
>>>>> 
>>>>> *  [e-mail], which is a new archival mailing list
>>>>> to preserve AUTH48 conversations; it is not an active discussion
>>>>> list:
>>>>> 
>>>>> *  More info:
>>>>>   https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>>> 
>>>>> *  The archive itself:
>>>>>   https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>> 
>>>>> *  Note: If only absolutely necessary, you may temporarily opt out
>>>>>   of the archiving of messages (e.g., to discuss a sensitive matter).
>>>>>   If needed, please add a note at the top of the message that you
>>>>>   have dropped the address. When the discussion is concluded,
>>>>>   [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/rfc9526.xml
>>>>> https://www.rfc-editor.org/authors/rfc9526.html
>>>>> https://www.rfc-editor.org/authors/rfc9526.pdf
>>>>> https://www.rfc-editor.org/authors/rfc9526.txt
>>>>> 
>>>>> Diff file of the text:
>>>>> https://www.rfc-editor.org/authors/rfc9526-diff.html
>>>>> https://www.rfc-editor.org/authors/rfc9526-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
>>>>> 
>>>>> Diff of the XML:
>>>>> https://www.rfc-editor.org/authors/rfc9526-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/rfc9526.original.v2v3.xml
>>>>> 
>>>>> XMLv3 file that is a best effort to capture v3-related format updates
>>>>> only:
>>>>> https://www.rfc-editor.org/authors/rfc9526.form.xml
>>>>> 
>>>>> 
>>>>> Tracking progress
>>>>> -----------------
>>>>> 
>>>>> The details of the AUTH48 status of your document are here:
>>>>> https://www.rfc-editor.org/auth48/rfc9526
>>>>> 
>>>>> Please let us know if you have any questions.
>>>>> 
>>>>> Thank you for your cooperation,
>>>>> 
>>>>> RFC Editor
>>>>> 
>>>>> --------------------------------------
>>>>> RFC9526 (draft-ietf-homenet-front-end-naming-delegation-27)
>>>>> 
>>>>> Title            : Simple Provisioning of Public Names for Residential Networks
>>>>> Author(s)        : D. Migault, R. Weber, M. Richardson, R. Hunter
>>>>> WG Chair(s)      : Kiran Makhijani, Stephen Farrell
>>>>> Area Director(s) : Erik Kline, Éric Vyncke
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>