AD review of draft-ietf-dhc-addr-notification-10

Dear authors, WG,

Thank you all for the work done in this *useful* document.

As usual, while processing the publication request for draft-ietf-dhc-addr-notification, I have done my AD review. Before proceeding further, i.e., IETF Last Call, I am requesting either a revised I-D addressing the points below or some more explanations.

Looking forward to reading your revised I-D

Regards

-éric


# Shepherd’s write-up

Tim, please add a justification for 6 authors (the normal limit is 5)

# Abstract

Should the plural form be added to ` has a self-generated or statically configured address` (i.e., putting “a” between parenthesis)

# Section 1

s/security purposes/forensics purposes/ ?

`IPv4 address can be retrieved` which IP address ? Laptop or printer ?

DHCP log or DHCP lease table ?

`one of the reasons which may be` should probably use a ‘that’ rather than a ‘which’.

Who is “it” in `it has a self-configured IPv6 address`?

# Section 3

I am disappointed to see only ASCII art and no SVG like in other related drafts from the same authors 😉 No need to reply of course.


Figure 1, suggest to also add the dst address. Why adding ‘code’ after OPTION_ADDR_REG_ENABLE in the first packet and not in the second ? Is there a typo in ADD-REG-REPLY ?



# Section 4.1



Should ‘and is willing’ be added in ` A server which supports the address registration mechanism` (cfr previous text on this topic)



# Section 4.2



Where should the client put the “Client Identifier” (even if 99% obvious, let’s be clear).



s/L2/layer-2/



Which address (MAC / IP) in `from spoofing other clients' addresses` ?



` The client MUST NOT send the ADDR-REG-INFORM message for addresses configured by DHCPv6.` what about the very special and rare case where not all multiple DHCPv6 servers have received the confirmation of address lease ?





# Section 4.2.1



In the case of multiple DHCPv6 servers, how can ` within a prefix delegated to the client`be checked ?



` SHOULD log the address registration information` should probably be more explicit about which information... I.e., DUID not always have MAC addresses.



` SHOULD mark the address as unavailable for use and not include it in future ADVERTISE messages` when can this SHOULD be bypassed ? I would assume that a MUST would be safer.



` SHOULD include the client's link-layer address in the relayed message` when can this SHOULD be bypassed ? I.e., without the client MAC, there is little use of this I-D.



# Section 4.3



s/ retansmit/ retransmit/

# Section 4.4

Should the client periodically try to register ? I fear that some statically addressed nodes will never register as they could stay for years without reboot or move.

# Section 4.6

Please expand and add a reference for PIO.

Is it ‘Discussion:’ or ‘Motivation:’ or ‘Justification:’ ?

What is meant by ` to match the another lifetime`?

# Section 6

Please expand DUID.

Be consistent about the use of ` Layer2 (link-layer)` (see previously L2)

s/ assigned/assigned/ ?

_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg