Skip to main content

Telechat Review of draft-ietf-dhc-addr-notification-11
review-ietf-dhc-addr-notification-11-intdir-telechat-bernardos-2024-05-09-00

Request Review of draft-ietf-dhc-addr-notification
Requested revision No specific revision (document currently at 13)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2024-05-10
Requested 2024-04-30
Requested by Éric Vyncke
Authors Warren "Ace" Kumari , Suresh Krishnan , Rajiv Asati , Lorenzo Colitti , Jen Linkova , Sheng Jiang
I-D last updated 2024-05-09
Completed reviews Intdir Telechat review of -11 by Carlos J. Bernardos (diff)
Dnsdir Telechat review of -12 by Jim Reid (diff)
Dnsdir Last Call review of -11 by Jim Reid (diff)
Genart Last Call review of -11 by Mallory Knodel (diff)
Secdir Last Call review of -11 by Peter E. Yee (diff)
Opsdir Last Call review of -11 by Niclas Comstedt (diff)
Comments
Even if DHC is in the INT area, having a review by INT-DIR will be a plus
Assignment Reviewer Carlos J. Bernardos
State Completed
Request Telechat review on draft-ietf-dhc-addr-notification by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/E6Lxr-PIxyyx5Dj_5Px4H3j6HBU
Reviewed revision 11 (document currently at 13)
Result Ready w/nits
Completed 2024-05-09
review-ietf-dhc-addr-notification-11-intdir-telechat-bernardos-2024-05-09-00
I am an assigned INT directorate reviewer for draft-ietf-dhc-addr-notification.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, if I was on the IESG I would ballot this document as YES.

I think the document is very well written and I personally find it very useful.

The following are minor issues (typos, misspelling, minor text improvements)
with the document:

- At the end of section 1, it is mentioned that the mechanism described in the
document provides parity with IPv4, by allowing a device to inform the DHCPv6
server about a self-configured or statically configured address. Apologies for
my ignorance on this in advance, but, is there a mechanism in IPv4 to do so for
statically configured addresses? If so, I think adding a reference would be
useful. If not, maybe the text can be rewritten a bit, as I would find it a bit
unclear.

- It is mentioned that the client MUST include the Client Identifier option in
the ADDRESS-REG-INFORM messages. I think this might deserve some text regarding
how this might imply (or not) a potential privacy issue for hosts implementing
some kind of MAC address randomization and rotation of IPv6 self-assigned
addresses, as an observer could easily track the addresses being used and match
those to the same device.

- It is not completely clear to me if the spec requires a client to use the
mechanism on ALL interfaces. I mean, can a client use it just on some
interfaces, but not all, by having configuration policies indicating on which
ones to use it? As I read the document, it seems to imply that if it is used on
one interface, it MUST be used on all of them.

- Minor nit (or maybe just nothing at it is just that I’m not a native English
speaker): “to specify the address to being registered” -> I guess the “to”
should be removed.