Early Review of draft-wkumari-dhc-addr-notification-07
review-wkumari-dhc-addr-notification-07-dnsdir-early-reid-2023-04-28-00
| Request | Review of | draft-wkumari-dhc-addr-notification |
|---|---|---|
| Requested revision | No specific revision (document currently at 07) | |
| Type | Early Review | |
| Team | DNS Directorate (dnsdir) | |
| Deadline | 2023-04-28 | |
| Requested | 2023-04-05 | |
| Requested by | Bernie Volz | |
| Authors | Warren "Ace" Kumari , Suresh Krishnan , Rajiv Asati , Lorenzo Colitti , Jen Linkova | |
| I-D last updated | 2023-04-28 | |
| Completed reviews |
Dnsdir Early review of -07
by Jim Reid
|
|
| Comments |
The DHC WG AD (Eric Vyncke) recommends an earlier review from the DNS directorate — “I would like to clear any potential objection to this I-D from the DNS experts who could prefer a DNS-update like approach.” There really isn’t much discussed in the draft related to DNS … references earlier work that was about having DNS updated and this version allows for client to notify DHCP server about FQDN but says nothing about what a server must do with that information. Thanks in advance for any comments provided. |
|
| Assignment | Reviewer | Jim Reid |
| State | Completed | |
| Request | Early review on draft-wkumari-dhc-addr-notification by DNS Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/dnsdir/n9JSVUd3wRRp-G6v4aGEz4RxQNE | |
| Reviewed revision | 07 | |
| Result | Almost ready | |
| Completed | 2023-04-28 |
review-wkumari-dhc-addr-notification-07-dnsdir-early-reid-2023-04-28-00
Metacomment: I'm not sure what is meant here by setting the state to completed. What's completed, the doc or the dnsdir review(s)? Setting this to partially completed is confusing too because it suggests an extra reviewer is to be assigned. Which is not the case for this I-D. Review comments: 1) I'd change "The lack of this parity with IPv4 is one of the reasons that some enterprise networks are unwilling to deploy IPv6." in Section 1 to "The lack of this parity with IPv4 is one of the reasons which may be hindering IPv6 deployment." ie The problem's not just in enterprise nets even if they're likely to be the most significant group of victims. 2) The description of the mechanism in Section 3 could be clearer. ie "this self-assigned IPv6 address" rather than "this address". What happens when a device has >1 interface? Could/should it send a multicast ADDR-REG-INFORM message on all of them? 3) I think client handling of the ADDR-REG-REPLY message needs more explanation. What checks, if any, are needed by the client to detect incorrect or spoofed responses? Which options MUST/MUST NOT be in the reply message header? Or does none of that matter? 4) The terminology in Section 6.1 is inconsistent: end-host, host etc. Pick one. I'd choose client since we're documenting a client-server protocol. That also fits nicely with the discussion of Client Identifier option. :-) Similar inconsistencies are found elswhere, like Section 7. These should all be tidied up too. 5) Section 6.1 says nothing about what a server should do about inappropriate requests. Presumably this should be logged. Maybe something needs to be returned to the client too? 6) 6.2 Should say "ADDR-REG-REPLY message MUST NOT be considered...". "It must not..." seems ambiguous. YMMV. 7) Typo in 6.4: s/can not/cannot/ 8) Is it only DCHP clients that are expected to allow the administrator to disable sending ADDR- REG-INFORM messages? Perhaps proxies or forwarders need to have that capability too. I'm a bit confused here because the I-D mostly talks about self-generated IPv6 addresses which probably won't involve DHCP. 9) Section 8 talks about ownership of IP addresses. It shouldn't use that term. The current user/holder of an IP address would be better IMO. 10) I want my money back because the I-D doesn't really have any DNS content. :-)