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
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
