Skip to main content

Early Review of draft-wkumari-dhc-addr-notification-07

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
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
Reviewed revision 07
Result Almost ready
Completed 2023-04-28
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.