Re: [homenet] AD review of draft-ietf-homenet-front-end-naming-delegation-16

[Daniel Migault <[e-mail]>]

Hi Eric,

Thanks for the clarification. I have reduced the list normative reference
by 10 items as shown in the PR [1].

Yours,
Daniel

[1]
https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/53/commits/5ce7aa5a82f253ab62ca27fe8a45f0206fc577d3#diff-1fb3d4609e8b03755bf2390df10a5ccd792f989796a0b922a273cd63418fcaa5





On Thu, Aug 11, 2022 at 7:38 AM Eric Vyncke (evyncke) <[e-mail]>
wrote:

> [2nd attempt as O365 has rejected my first reply...]
>
>
>
> Hello Daniel,
>
>
>
> Thanks for the changes except for the references, the goal of the
> normative/informative is not ‘to pass the id-nits’ examination but rather
> to give the readers the list of what they MUST read to implement
> (normative) and the list of useful links to understand (informative)
>
>
>
> Regards,
>
>
>
> -éric
>
>
>
> PS: going in vacation mode for one week...
>
>
>
> *From: *Daniel Migault <[e-mail]>
> *Date: *Wednesday, 10 August 2022 at 18:00
> *To: *Eric Vyncke <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [homenet] AD review of
> draft-ietf-homenet-front-end-naming-delegation-16
>
>
>
> Hi Eric,
>
>
>
> Thanks for the response. Just to follow-up on the latest comments
>
>
>
> On Tue, Aug 9, 2022 at 2:11 AM Eric Vyncke (evyncke) <[e-mail]>
> wrote:
>
> Hello Daniel,
>
>
>
> Thank you for the quick reply. I had a quick browse through the commit and
> it seems that some points are yet to be addressed:
>
>    - List of normative references [1]
>
> Currently we set the normative and informational references so it passes
> the checks. As a result any standard track reference is moved to the
> normative section and informational references are moved to the informative
> section. . I am wondering if you are requesting that we only keep the
> essential normative references in the normative sections - that is the
> references that are mandatory to be considered.  If that is the case, this
> could lead to a standard track reference being moved to the informative
> section.   Before we proceed to the changes, we just would like to make
> sure this is what is expected.
>
>
>
>
>    - RFC 7404 is not specifying LLA ;-)
>
>  This is correct but it explains how to use them. We updated LLA
> references for IPv4/IPv6 as follows:
>
>
>
> A device or service may have Global Unicast Addresses (GUA) (IPv6
> {{?RFC3787}} or IPv4), a Unique Local IPv6 Address (ULA) {{?RFC4193}}, as
> as well IPv6-Link-Local addresses{{!RFC4291}}{{!RFC7404}}, IPv4-Link-Local
> Addresses {{!RFC3927}} (LLA), and private IPv4 addresses {{!RFC1918}}.
>
>
>    - s/ as as well/as well as/ ?
>
> changed
>
>
>    -
>    - no justification for ‘one to three’ in section 1.2, simply remove
>    those words
>
> The justification we added was a plausible list of instances, but we are
> fine removing it.
>
> OLD:
>
> For a very few numbers (one to three) of hosts (media servers, VPN
> gateways, ... ),
>
> NEW:
>
> For a very few numbers of hosts,
>
>
>    -
>
>
>
> Yours,
>
> Daniel
>
> Please continue the good work
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> [1] I am sure that you know
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
>
>
>
> *From: *Daniel Migault <[e-mail]>
> *Date: *Tuesday, 9 August 2022 at 04:21
> *To: *Eric Vyncke <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [homenet] AD review of
> draft-ietf-homenet-front-end-naming-delegation-16
>
>
>
> Hi Erik,
>
>
>
> Thanks for the careful review. That is really much appreciated. We have
> addressed most of the changes in line as well as here:
>
>
> https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/f9157a3db159dc327a3e9d5c85e9f9f83a458729
>
>
>
> There is one remaining change we need to make,  and I hope we will be able
> to submit a new version in the coming days. Feel free to let us know if the
> changes are addressing your concerns.
>
>
>
> Yours,
> Daniel
>
>
>
> On Mon, Aug 8, 2022 at 9:31 AM Eric Vyncke (evyncke) <evyncke=
> [e-mail]> wrote:
>
> As usual, I do my own review before requesting the IETF Last Call for all
> documents. The intent is to give another polishing pass on the I-D.
>
>
>
> For this review, the MD format is used.
>
>
>
> Hope this helps
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> # Éric Vyncke, INT AD, comments for
> draft-ietf-homenet-front-end-naming-delegation-16
>
> CC @evyncke
>
>
>
> Thank you for the work put into this document. Multiple nits and typos are
> identified in the end of this review, I would have expected a document that
> has been through spell and grammar checkers.
>
>
>
> Please find below one blocking DISCUSS points (easy to address), some
> non-blocking COMMENT points (but replies would be appreciated even if only
> for my own education), and some nits.
>
>
>
> Special thanks to Stephen Farrel for the shepherd's detailed write-up
> including the WG consensus, *but* it lacks the justification of the
> intended status.
>
>
>
> I hope that this review helps to improve the document,
>
>
>
> Regards,
>
>
>
> -éric
>
>
>
> ## DISCUSS
>
>
>
> ### id-nits, references to be updated
>
>
>
> Please have a look at
> https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-16.txt
> and address the updated references.
>
>
>
> ### id-nits, downref
>
>
>
> As noted by Stephen in his review (and I second his proposal), several
> normative references should probably "just" informative.
>
>
>
>  downref have been moved to informative
>
> ### HNA certs
>
>
>
> >From my reading of the text, it is really unclear whether HNA certs are /
> may be self-signed and what the subject alt name is (IP address ? FQDN ?
> other).
>
>
>
> The text does not specify how certificate authentication is performed and
> leaves it relatively open to what TLS supports. Since the communication
> between the DM and the HNA is mutually authenticated there are two
> certificates involved: the certificates of the HNA and the certificate of
> the  DM.
>
> In most deployments the DM is expected to be authenticated using the web
> PKI or alternatively using DANE or when the HNA is completely provisioned
> with some provisioned keys. To authenticate the HNA, the DM may need to
> bind the HNA to a registered client with the associated Registered Homenet
> Domain.
>
> There are multiple ways, one is that the certificate contains an account
> reference as well as the FQDN which could be both inserted in the SAN (URN
> and FQDN). Other deployments may only have certificates with the FQDN... It
> is highly probable that the DM will trust the information based on the  CA
> that issued the certificate - which as I imagine is likely to belong to the
> same organization as the DM. On the other hand, a Let's encrypt certificate
> may also be acceptable.
>
>
>
> The current text in Section "Securing the Control Channel" omits all
> details and is as mentioned below:
>
>
>
> OLD:
>
> The DM SHOULD authenticate the HNA and check that inbound messages are
> from the appropriate client.
>
> The DM MAY use a self-signed CA certificate mechanism per HNA, or public
> certificates for this purpose.
>
>
>
> I propose the following text, please let me know if that addresses your
> concern.
>
>
>
> NEW:
>
> The DM SHOULD authenticate the HNA and check that inbound messages are
> from the appropriate client.
>
> The DM MAY use a self-signed CA certificate mechanism per HNA, or public
> certificates for this purpose.
>
> The HNA certificate needs to provide sufficient trust to the DM that the
> HNA is legitimate. When certificates are used, it is left to the DM to
> define what information carried by the certificate is acceptable as well as
> which CA can issue the certificate. For example, some deployments may use
> domain validation certificates with the Registered Homenet Domain as a SAN
> of type FQDN. Other deployments may use specifically formed certificates
> with additional information such as a user account as a SAN of type URN,
> signed by a specific CA may be used.
>
>
>
>
>
> ### Section 1, multiple IP addresses
>
>
>
> In `A device may have a Global Unicast Address (GUA),`, it appears by the
> use of 'a' that devices can have only one. Suggest removing 'a'.
>
>
>
> In the same vein, even in residential network, there may be global IPv4
> addresses.
>
>
>
> changed to:
>
> A device may have Global Unicast Addresses (GUA) (IPv6 or IPv4), a Unique
> Local IPv6 Address (ULA), as as well IPv6-Link-Local addresses,
> IPv4-Link-Local      Addresses, and RFC1918 addresses.
>
> ### Section 1.2, 1 to 3 ?
>
>
>
> Please justify the limit to 3 in `For a very few number (one to three) of
> hosts`
>
>
>
> changed to:
>
> For a very few number (one to three) of hosts (media servers, VPN
> gateways, .     .. ),...
>
> ### Section 1.2, requirements ?
>
>
>
> Please add a reference (or rephrase) the requirement in `Such dependence
> does not meet the requirement for`.
>
>
>
> adding  {{?RFC7368}} as a reference of the requirement.
>
> ### Section 2, Homenet Authoritative Servers:
>
>
>
> For which zones `Homenet Authoritative Servers:` ?
>
>
>
> adding:
>
> for the  Homenet Zone
>
> ### Section 3.2
>
>
>
> The I-D proposes to use DoH & DoQ as transport, but did the authors check
> that AXFR operations can be made over DoH ?
>
>  I am not aware of this being standardized but I do not see anything that
> could prevent it.
>
>
>
> The current text I see mentioning DoH and DoQ are as follows:
>
>
>
> The information exchanged between the HNA and the DM uses DNS messages
> protected by DNS over TLS (DoT) {{!RFC7858}}.
> Other specifications may consider protecting DNS messages with other
> transport layers, among others, DNS over DTLS {{?RFC8094}}, or DNS over
> HTTPs (DoH) {{?RFC8484}} or DNS over QUIC {{?RFC9250}}.
>
>
>
> I do see some confusion that QUIC or DoH are not clearly identified as not
> supporting AXFR (now). I propose the following change:
>
> In the future, other specifications may consider protecting DNS messages
> with other transport layers, among others, DNS over DTLS {{?RFC8094}}, or
> DNS over HTTPs (DoH) {{?RFC8484}} or DNS over QUIC {{?RFC9250}}.
>
>
>
> The other place I found is there and I do not think any other changes are
> needed.
>
>
>
> Supported Transport (dm\_transport)
> : The transport that carries the DNS exchanges between the HNA and the DM.
> Typical value is "DoT" but it may be extended in the future with "DoH",
> "DoQ" for example.
>
> This parameter is OPTIONAL and by default the HNA uses DoT.
>
> ### Section 4.5.4 SHOULD ?
>
>
>
> Please explain when the 'SHOULD' does not apply.
>
>
>
> SHOULD has been removed.
>
>
>
> ### Section 5, port XX
>
>
>
> As the XX on DM is 853, does it require the HNA to also listen on XX ==
> 853 ?
>
>
>
> Yes for the synchronization channel:
>
>
>
> On the other hand, the Synchronization Channel is set between the DM
> working as a client using port ZZZZ ( a high range port) toward a service
> provided  by the HNA at port XX.
>
> ### Section 5
>
> ```
>
>    The use of a primary / secondary mechanism is RECOMMENDED instead of
>
>    the use of DNS Update
>
> ```
>
>
>
> What is 'primary/secondary mechanism' ? Missing transfer ?
>
>
>
> 'DNS update' is it the HTTP RESTful one ? Is it the same as 'DNS UPDATE
> [RFC2136]' used later in the section ?
>
>
>
> I think the most accurate reference for primary / secondary is 1996. The
> mechanisms was described a master / slave. Yes DNS Update is DNS UPDATE. I
> added the two references and the text has been changed as follows:
>
>
>
>  The use of a primary / secondary mechanism {{!RFC1996}} is RECOMMENDED
> instead of the use of DNS UPDATE {{?RFC2136}}.
>
>
>
> We changed all DNS Update to DNS UPDATE as well.
>
> ### Section 11.3
>
>
>
> Who is the end user in :
>
> ```
>
>    ... For
>
>    that reason end users may choose not to respond to PTR DNS queries
>
>    and MAY instead return a NXDOMAIN response.
>
> ```
>
> You are correct this is the end-user / admin. ;-)
>
>
>
> OLD:
>
> For that reason end users may choose not to respond to PTR DNS queries and
> MAY instead return a NXDOMAIN response.
>
>
>
> NEW:
>
> For that reason PTR DNS queries and MAY instead be configured to return
> with NXDOMAIN.
>
>
>
> ### Appendix A, why in appendix ?
>
>
>
> Is there a reason why the reverse zone is in the appendix ? There should
> at least be a forward reference in the introduction to the appendix but
> better to move in the main body.
>
>
>
> Re-added in the body. The reason it has been put in the appendix is that
> it is a variant of the forward zone - that is a specific case. On the other
> hand, it could be also seen as an essential part of the architecture.
>
>
>
> ## COMMENTS
>
>
>
> ### Shepherd's review, intended status
>
>
>
> Stephen, as noted above, please include some justification for the
> intended PS status.
>
>
>
> ### Section 1, devices or services ?
>
>
>
> ```
>
>    Home network owners often have devices that they wish to access
>
>    outside their home network - i.e., from the Internet using their
>
>    names.
>
> ```
>
>
>
> As DNS contains more than mere IP addresses and as a single device can
> host many services with different IP addresses, propose to use 'devices and
> services'.
>
>
>
> This issue also appears in other sections (e.g., sect 1.1)
>
>
>
> we updated 6 ish occurrences.
>
> ### Section 1.1, un-parsable ?
>
>
>
> Is it parsable for a native-English speaker ?
>
> ```
>
>    While this document does not create any normative mechanism by which
>
>    the selection of names to publish,
>
> ```
>
>
>
>  I think the wording below might be better
>
>
>
> While this document does not create any normative mechanism to select the
> names to publish, this document anticipates that the home network
> administrator      (a human), will be presented with a list of current
> names and addresses.
>
>
>
> ### Section 1.1, inside ?
>
>
>
> Please define (or add a reference) for `on the inside of the home`.
>
>
>
> see above.
>
> ### Section 1.1, DHCP rebinding ?
>
>
>
> The reference to RFC 6644 is a little weird to me, either use 'DHCP
> rebind' or use the right RFC for DHCPv6.
>
> The reference to DHCPv6 has been updated and the sentence is as follows:
>
> The address of the device or service can be collected from a number of
> places     : mDNS {{!RFC6762}}, DHCP {{!RFC8415}}, UPnP, PCP {{!RFC6887}},
> or manual con     figuration.
>
>
>
> ### Section 1.1, RFC 1918 or private
>
>
>
> Please add a reference to ULA and use 'private IPv4 addresses' rather than
> 'RFC 1918 addresses' ?
>
>
>
> Here is the updated text:
>
>
>
> A device or service may have Global Unicast Addresses (GUA) (IPv6
> {{?RFC3787}} or IPv4), a Unique Local IPv6 Address (ULA) {{?RFC4193}}, as
> as well IPv6-Link-Local addresses, IPv4-Link-Local Addresses (LLA)
> {{?RFC7404}}, and private IPv4 addresses {{!RFC1918}}.
>
> ### Section 1.1, TLS ?
>
>
>
> Why is TLS mentioned here ? It should rather be in the security section.
>
>
>
> I think the text is expected to highlight that name are global identifiers
> even if local scope IP addresses are used.
>
>
>
> The old text was:
>
> In general, one expects the GUA to be the default address to be published.
> However, publishing the ULA and RFC1918 may enable local communications
> within the home network.
> Since the communication has been initiated with a name which remains a
> global identifier, the communication can be protected by TLS the same way
> it is protected on the global Internet.
> A direct advantage of enabling local communication is to prevent
> communications even in case of Internet disruption.
>
>
>
> Perhaps the new text below is clearer:
>
>
>
> In general, one expects the GUA to be the default address to be published.
>
> However, publishing the ULA and RFC1918 may enable local communications
> within the home network.
> A direct advantage of enabling local communication is to
> enable communications even in case of Internet disruption.
>
> However, since communications are established with names which remains a
> global identifier, the communication can be protected by TLS the same way
> it is protected on the global Internet.
>
> ### Section 1.1
>
>
>
> This is probably the reverse:
>
> ```
>
> A direct advantage of enabling local
>
>    communication is to prevent communications even in case of Internet
>
>    disruption.
>
> ```
>
>
>
> changed prevent to enable
>
> ### Section 1.2
>
>
>
> `As there are some commonalities provides by individual home` possibly a
> typo.
>
>
>
> change provides to provided
>
> ### Section 3.1, which network ?
>
>
>
> In `When the request is coming within the network`, which network ? Even
> if guessable, let's be clear.
>
>
>
> changed to:
>
> When the request is coming within the home network,
>
>
>
> ### Section 3.1
>
>
>
> Should '.local' also appear in figure 1?
>
>
>
> My understanding is that .local is mostly used with DNSSD which is
> advertised via multicast as opposed to a zone. For that reason home.arpa
> seems more appropriated. Now it is also correct that there are some
> mechanisms that convert .local advertised via DNSSD into a zone, but I
> think such considerations are a bit out of scope of the document.
>
> ### Section 3.2
>
>
>
> What is `cloud provider's anycast addresses`?
>
>
>
>  The anycast address is the address used by the cloud provider to
> distribute the homenet zone. I agree this is not necessarily an anycast
> address though I think it clearly shows the interest of using a cloud
> provider with specific properties.
>
>
>
> Perhaps the following change can clarify the text:
>
>
>
> OLD:
>
> The visible NS records SHOULD remain pointing at the cloud provider's
> anycast addresses.
>
>
>
> NEW:
>
> The visible NS records SHOULD remain pointing at the cloud provider's
> server IP address -- which in many cases will be an anycast addresses.
>
>
>
> ### Section 4.6 oxymoron ?
>
>
>
> Isn't `The DM MAY use a *self-signed CA* certificate mechanism per HNA` an
> oxymoron ?
>
>
>
> I think what the text is trying to say is that the DM may use a dedicated
> CA specifically provisioned for the service and dedicated to issue
> certificates for HNA.
>
> I agree that the text can be hard to parse and considering that we already
> changed some of the initial text in a previous comment, I think we can
> simply remove the sentence.
>
> The full paragraph would move from :
>
>
>
> OLD:
>
> The DM SHOULD authenticate the HNA and check that inbound messages are
> from the appropriate client.
> The DM MAY use a self-signed CA certificate mechanism per HNA, or public
> certificates for this purpose.
> The HNA certificate needs to provide sufficient trust to the DM that the
> HNA is legitimate. When certificates are used, it is left to the DM to
> define what information carried by the certificate is acceptable as well as
> which CA can issue the certificate. For example, some deployments may use
> domain validation certificates with the Registered Homenet Domain as a SAN
> of type FQDN. Other deployments may use specifically formed certificates
> with additional information such as a user account as a SAN of type URN,
> signed by a specific CA may be used.
>
>
>
> TO:
>
> The DM SHOULD authenticate the HNA and check that inbound messages are
> from the appropriate client.
> The HNA certificate needs to provide sufficient trust to the DM that the
> HNA is legitimate. When certificates are used, it is left to the DM to
> define what information carried by the certificate is acceptable as well as
> which CA can issue the certificate. For example, some deployments may use
> domain validation certificates with the Registered Homenet Domain as a SAN
> of type FQDN. Other deployments may use specifically formed certificates
> with additional information such as a user account as a SAN of type URN,
> signed by a specific CA may be used.
>
>
>
> ### Section 4.6, ambiguous
>
>
>
> In `The DM MAY use a self-signed CA certificate mechanism per HNA`, is
> this cert used to verify the connection from HNA or rather used by the DM
> to sign its messages ?
>
>
>
> It is for the DM to authenticate the HNA. I think the text above clarifies
> this as well.
>
> ### Section 4.7 SHOULD
>
>
>
> When can an implementation not follow the "SHOULD" ?
>
>
>
> The text in question is as follows:
>
>
> Limited exchanges:
> : the purpose of the Hidden Primary Server is to synchronize with the DM,
> not to serve any zones to end users, or the public Internet.
> This results in a limited exchanges (AXFR/IXFR) with a small number of IP
> addresses and such limitations SHOULD be enforced by policies described in
>  {{sec-cpe-sec-policies}}.
>
>
>
>
>
> The intent is to say that the implementation SHOULD enable filtering
> unexpected DNS packets and IP addresses. I think the following sentence may
> be clearer:
>
> This results in a limited number of possible exchanges (AXFR/IXFR) with a
> small number of IP addresses and an implementation SHOULD enable filtering
> policies as described in  {{sec-cpe-sec-policies}}.
>
>
>
> ### Section 3, synchronization or transfer
>
>
>
> Just wondering whether 'synchronization' is the best word (as it is mainly
> HNA updated one-way the DM), why not simply 'transfer' ?
>
>  I am obviously biaised, but I do think that synchronization is more
> appropriated as the channel is used to tranfer as well as to check the file
> version to ensure both primary and secondary have the same version of the
> zone file.
>
> ### Section 5
>
>
>
> A small figure would be nice.
>
> Actually Figure 1 mentions all channels. Do you think we should remind the
> reader about this or do you expect another figure ?
>
>
>
> ### Section 5, CPE only
>
>
>
> ```
>
>    The HNA acts as a Hidden Primary Server, which is a regular
>
>    authoritative DNS Server listening on the WAN interface.
>
> ```
>
>
>
> Does this mean that only CPE can be a HNA ? Then, what about the previous
> paragraphs about multiple HNA at home?
>
>
>
> Practically this is expected to be the most common case, but HNA is not
> necessarily a CPE. When there are multiple candidates for the HNA, we need
> to pick one.
>
> I think we have some text that mentions this but feel free to let me
> know if I am missing something.
>
>
>
> Note that there is no standard way to distribute a DNS primary between
> multiple devices.
> As a result, if multiple devices are candidate for hosting the Hidden
> Primary, some specific mechanisms should be designed so the home network
> only selects a single HNA for the Hidden Primary.
> Selection mechanisms based on HNCP {{!RFC7788}} are good candidates.
>
>
>
> ### Section 5.1
>
>
>
> Please also add which parties are the primary and secondary.
>
>
>
> I suppose  the correspondence between HNA / DM and primary / secondary is
> missing. I propose the following change:
>
>
>
> OLD:
>
> First the primary notifies the secondary that the zone must be updated and
> leaves the secondary to proceed with the update when possible/convenient.
>
>
>
> NEW:
>
> First the HNA (primary) notifies the DM (secondary) that the zone must be
> updated and leaves the DM (secondary) to proceed with the update when
> possible/convenient.
>
>
>
> Note that I also changed the exchange description that seems like an
> additional procedure  as opposed to a more detailed description of the high
> level mechanism just described above. I think that was part of the
> confusion and the text is now as follows:
>
>
>
> More specifically, the HNA sends a NOTIFY message, which is a small packet
> that is less likely to load the secondary.
> Then, the DM sends  AXFR {{!RFC1034}} or IXFR {{!RFC1995}} request. This
> request consists in a small packet sent over TCP (Section 4.2
> {{!RFC5936}}), which also mitigates reflection attacks using a forged
> NOTIFY.
>
>
>
> ### Section 5.1, DNS resolution
>
>
>
> Humm is `(via DNS resolution)` normative ?
>
>
>
> change to via a DNS resolution
>
> When can the last 'SHOULD' be ignored ?
>
>
>
> The SHOULD is likely to be ignored on minimal implementations. The
> additional SHOULD describes a mechanism to make the mechanism more stable
> but that is not strictly mandatory.
>
> ### Section 7, SHOULD
>
>
>
> Please explain when the 'SHOULD' can be ignored.
>
>
>
> The first SHOULD has been changed from:
>
> OLD:
>
> The HNA, as Hidden Primary SHOULD drop any DNS queries from the home
> network.
>
> NEW:
>
>  The HNA, as Hidden Primary SHOULD drop any DNS queries from the home
> network -- as opposed to return DNS errors.
>
>
>
> The second SHOULD has been changed to :
>
>
>
> OLD:
>
> The HNA SHOULD drop any packets arriving on the WAN interface that are not
> issued from the DM.
>
>
>
> NEW:
>
> The HNA SHOULD drop any packets arriving on the WAN interface that are not
> issued from the DM -- as opposed to server as an Homenet Authoritative
> Server exposed on the Internet.
>
> ### Section 9, reverse zone
>
>
>
> In `it is RECOMMENDED that only the newly reachable IP addresses be
> published`, what is the recommendation for the reverse zone(s) ?
>
>
>
>  As the HNA does not really own the reverse zone, once the IP address is
> not valid anymore, the HNA is expected to have no control over the reverse
> zone. As a result, I do not see any action to be done by the HNA for the
> reverse zone.
>
>
>
> That said, we can probably detail this a bit. The added text is as follows:
>
> Regarding the Homenet Reverse Zone, the new Homenet Reverse Zone has to
> be populat
> ed as soon as possible, and the old Homenet Reverse Zone will be deleted
> by the ow
> ner of the zone (and the owner of the old prefix which is usually the ISP)
> once th
> e prefix is no longer assigned to the HNA. The ISP SHOULD ensure that the
> DNS cach
> e has expired before re-assigning the prefix to a new home network. This
> may be en
> forced by controlling the TTL values.
>
> ### Section 10
>
>
>
> Suggest moving section 10 as a sub-section of section 11.
>
>
>
> ### Section 10
>
>
>
> No clue of to understand:
>
> ```
>
>    For instance, an adult child checking on the
>
>    state of a home automation system for a parent.
>
> ```
>
>
>
> *I need to check * this with my co-authors.
>
>
>
> ### Section 11.2
>
>
>
> Should temporary IPv6 addresses be mentioned as well ?
>
>
>
> We have added some text and the current paragraph looks like this:
>
>
>
> IP addresses may be used to locate a device, a host or a service.
>
> However, home networks are not expected to be assigned a time invariant
> prefix by ISPs. In addition IPv6 enables temporary addresses that makes
> them even more volatile {{!RFC8981}}.
>
> ### Section 11.4
>
>
>
> Please rename this section to something else as it is not the usual
> 'operational considerations' section.
>
>
>
> changed to deployment considerations
>
> ### Appendix A
>
>
>
> ```
>
>    In the case of the reverse zone, the DOI authenticates the source of
>
>    the updates by IPv6 Access Control Lists.
>
> ```
>
> DOI or DM ?
>
>
>
> The DM is part of the DOI, so that will not become fundamentally wrong.
> The reason we keep DOI is that the DM is essentially focused on DNS aspects
> while authentication is likely to be defer to a dedicated function
> different from the DOI. I tend to refer DOI.
>
>
>
> ### Appendix A.1
>
>
>
> s/2001:db8:aeae:0001::2/2001:db8:aeae:1::2/
>
>
>
> Does this mean 2 control channels (one for WAN and one for inside LAN) ?
>
>
>
> I think this is just one IP of the network. We probably did not take :2 as
> something generic as opposed to :1 or :0, but I am happy to hear what seems
> to you a better choice.
>
> Unsure whether the following is true:
>
> ```
>
>    With IPv6, the domain space for IP addresses is so large that reverse
>
>    zone may be confronted with scalability issues.
>
> ```
>
>
>
> The reverse zone associated to ::/64 can be non trivial to manage
> especially when very few IPs are effectively being used. I suspect the
> wording is unclear and propose to replace it as follows:
>
>  With IPv6, the reverse domain space for IP addresses associated to
> a subnet such as ::/64 is so large that reverse zone may be confronted with
> scalability issues.
>
>
>
> ### Appendix A.2
>
>
>
> s/RG router/CPE/
>
>
>
> ok
>
> ### Appendix B
>
>
>
> Is not normative, then is it useful ?
>
>
>
> What is 'front-end protocol' ?
>
>
>
> The front end protocol is the legacy name for the protocol described in
> this document. I think the section gives a good sense of how the HNA needs
> to be provisioned and configured, s I think that is important to have such
> a section.
>
>
>
> ### Appendix B.1
>
>
>
> Hmm a little unclear at first sight whether this section is explaining the
> parameters of appendix B.
>
> agree the twp sections have been merged.
>
>
>
> ### Appendix C
>
>
>
> Even if not normative, use cases are often described in the introduction
> section. Consider moving this appendix in section 1.
>
>
>
> moved as section 1.3
>
>
>
> ## NITS
>
>
>
> ### Abstract & section 1
>
>
>
> s/needs/need/
>
>
>
> ok
>
> ### Section 1.1
>
>
>
> s/home network administrator (a human), will be presented with a list/home
> network administrator, (a human being), will be presented with a list/ ?
>
>
>
> ok
>
> ### Section 1.2
>
>
>
> s/For a very few number/For a very few numbers/ ?
>
>  ok
>
>
>
> ### Section 4.2
>
>
>
> `so the that DOI`? how to parse this ?
>
> changed to: so the DOI
>
>
>
> ### No comma before 'and'
>
>
>
> AFAIK, there is no comma before 'and', exception made for the Oxford comma
> of course.
>
>
>
> ok - works for me.
>
> ### Section 4.2
>
>
>
> s/were/was/ ?
>
>
>
> I cannot find it in section 4.2 it might have been changed addressing a
> previous comment.
>
> ### Section 4.5
>
>
>
> s/long term session/long-term session/
>
>
>
> ok
>
> ### Section 4.6
>
>
>
> Unbalanced parenthesis.
>
>
>
> ok
>
> ### Section 4.7
>
>
>
> s/describe din/described in/
>
> ok
>
>
>
> ### Section 5
>
>
>
> Duplicate `toward a service a service`
>
>
>
> ok
>
> ### Section 6
>
>
>
> s/is outside/are outside/ ?
>
>
>
> ok
>
> ### Non-empty well-known
>
>
>
> Several missing '-' in 'non-empty' and 'well-known' (when applicable).
>
>
>
> ok
>
> ### E.g.
>
>
>
> "E.g." should be enclosed in ','.
>
>
>
> ok
>
> ### Section 9
>
>
>
> 'by by' ?
>
> ok
>
>
>
> ### Section 10
>
>
>
> s/privacy MAY be provide/privacy MAY be provided/
>
>
>
> ok
>
> ### Section 11.1
>
>
>
> `To ensure the multiple TLS session are are continuously authenticating `
> duplicated 'are'
>
> ok
>
>
>
> s/This MAY Be handle by a off-line /This MAY be handled by an off-line/
>
>
>
> ok
>
> ### DNS in uppercase
>
>
>
> There are a couple of 'dns' (lowercase) instances.
>
>
>
> ok
>
> ## Notes
>
>
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use
> the
>
> [`ietf-comments` tool][ICT] to automatically convert this review into
>
> individual GitHub issues.
>
>
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
>
> [ICT]: https://github.com/mnot/ietf-comments
>
>
>
>
>
>
>
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet
>
>
>
>
> --
>
> Daniel Migault
>
> Ericsson
>
>
>
>
> --
>
> Daniel Migault
>
> Ericsson
>


-- 
Daniel Migault
Ericsson