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

["Eric Vyncke (evyncke)" <[e-mail]>]

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.



### 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).



### 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.



### Section 1.2, 1 to 3 ?



Please justify the limit to 3 in `For a very few number (one to three) of hosts`



### Section 1.2, requirements ?



Please add a reference (or rephrase) the requirement in `Such dependence does not meet the requirement for`.



### Section 2, Homenet Authoritative Servers:



For which zones `Homenet Authoritative Servers:` ?



### 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 ?



### Section 4.5.4 SHOULD ?



Please explain when the 'SHOULD' does not apply.



### Section 5, port XX



As the XX on DM is 853, does it require the HNA to also listen on XX == 853 ?



### 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 ?



### 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.

```



### 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.



## 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)



### 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,

```



### Section 1.1, inside ?



Please define (or add a reference) for `on the inside of the home`.



### 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.



### Section 1.1, RFC 1918 or private



Please add a reference to ULA and use 'private IPv4 addresses' rather than 'RFC 1918 addresses' ?



### Section 1.1, TLS ?



Why is TLS mentioned here ? It should rather be in the security section.



### 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.

```



### Section 1.2



`As there are some commonalities provides by individual home` possibly a typo.



### Section 3.1, which network ?



In `When the request is coming within the network`, which network ? Even if guessable, let's be clear.



### Section 3.1



Should '.local' also appear in figure 1?



### Section 3.2



What is `cloud provider's anycast addresses`?



### Section 4.6 oxymoron ?



Isn't `The DM MAY use a *self-signed CA* certificate mechanism per HNA` an oxymoron ?



### 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 ?



### Section 4.7 SHOULD



When can an implementation not follow the "SHOULD" ?



### 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' ?



### Section 5



A small figure would be nice.



### 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?



### Section 5.1



Please also add which parties are the primary and secondary.



### Section 5.1, DNS resolution



Humm is `(via DNS resolution)` normative ?



When can the last 'SHOULD' be ignored ?



### Section 7, SHOULD



Please explain when the 'SHOULD' can be ignored.



### 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) ?



### 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.

```



### Section 11.2



Should temporary IPv6 addresses be mentioned as well ?



### Section 11.4



Please rename this section to something else as it is not the usual 'operational considerations' section.



### 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 ?



### 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) ?



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.

```



### Appendix A.2



s/RG router/CPE/



### Appendix B



Is not normative, then is it useful ?



What is 'front-end protocol' ?



### Appendix B.1



Hmm a little unclear at first sight whether this section is explaining the parameters of appendix B.



### Appendix C



Even if not normative, use cases are often described in the introduction section. Consider moving this appendix in section 1.



## NITS



### Abstract & section 1



s/needs/need/



### 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/ ?



### Section 1.2



s/For a very few number/For a very few numbers/ ?



### Section 4.2



`so the that DOI`? how to parse this ?



### No comma before 'and'



AFAIK, there is no comma before 'and', exception made for the Oxford comma of course.



### Section 4.2



s/were/was/ ?



### Section 4.5



s/long term session/long-term session/



### Section 4.6



Unbalanced parenthesis.



### Section 4.7



s/describe din/described in/



### Section 5



Duplicate `toward a service a service`



### Section 6



s/is outside/are outside/ ?



### Non-empty well-known



Several missing '-' in 'non-empty' and 'well-known' (when applicable).



### E.g.



"E.g." should be enclosed in ','.



### Section 9



'by by' ?



### Section 10



s/privacy MAY be provide/privacy MAY be provided/



### Section 11.1



`To ensure the multiple TLS session are are continuously authenticating ` duplicated 'are'



s/This MAY Be handle by a off-line /This MAY be handled by an off-line/



### DNS in uppercase



There are a couple of 'dns' (lowercase) instances.



## 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