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-naming-architecture-dhc-options-16 CC @evyncke Thank you for the work put into this document. Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). 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 (and the WGLC was extended to the DHC WG). I hope that this review helps to improve the document, Regards, -éric ## DISCUSS ### Section 4.2 port ? The DHCP option does not allow to run DoT over a non-standard port. Or if another transport is defined without an associated default port, then there is no way to specify a port. ### Section 6 sub-sections As there are two IANA requests, please use 2 sub-sections, one per request. ### Section 6 reference For the request about option codes, in the table add the obvious 'this document' in the to-be-added column 'Reference' + the relevant section number. ### Section 6 registry s/IANA is requested to maintain a new number space/IANA is requested to create a new registry/ Also follow RFC 8126 section 1.3 (and others) by notably adding a description, the parent grouping (DHC I guess) ### Appendix B and its sub-sections Please use foo.example to stick to the example TLDs. ## COMMENTS ### Shepherd's review, intended status Stephen, as noted above, please include some justification for the intended PS status. ### Abstract An 'agnostic' HNA is only defined in the appendix of the main document and is unclear without this context. Suggest to remove this word. ### Section 2 DOI Isn't it 'DNS Outsourcing Infrastructure' ? ### Section 2 DOI or DM ? ``` This document describes how a network can provision the HNA with a specific DOI. ``` Is it DOI or DM? ### Section CE or CPE Please use CPE to be consistent with the companion document. ### Section 4.2 option name By consistency with section 4.3, should this be OPTION_FORWARD_DIST_MANAGER ? ### Section 4.2 FQDN Some explanations about the use of a FQDN vs. IP addresses would be welcome. ### Section 4.2.1 flow As this section is also used by section 4.3, suggestion to move it after section 4.3 as section 4.4 ### Section 6 spec required I am concerned that 'spec required' is enough for such a 16-bit flags field. Should it be 'RFC required' ? ### References Unsure whether ietf-homenet-front-end-naming-delegation is normative, it is rather informative. Same for RFC 9103 and RFC 7858 ### App B The 1st and 3rd paragraph are quite repetitive. ### Appendix, why here ? There is little DHCP-related content in the appendix and the scenario would probably be more useful in the companion document. ## 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
