Re: [dhcwg] AD review of draft-ietf-dhc-addr-notification-10

[Warren Kumari <[e-mail]>]

On Fri, Apr 05, 2024 at 10:38 AM, Eric Vyncke <[e-mail]> wrote:

> 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.
>
>
>

Ta!

I'm creating a Github PR for my co-authors to review, which addresses many
of your comments (proposed resolutions below). Some of them will still need
more discussion, but I / we wanted to reply to at least acknowledge your
mail.


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)
>


I think that that read a little funny, so how is:
"that a device has one or more self-generated or statically configured
addresses."?


>
> # Section 1
>
>
>
> s/security purposes/forensics purposes/ ?
>


SGTM, thanks, done.


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


Proposed "the printer's IPv4 address can". Thanks.


>
> DHCP log or DHCP lease table ?
>


Proposed  "can be retrieved from the DHCP log or lease table and the
printer pinged".
Thanks.


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

Thanks.


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


Proposed "inform the DHCPv6 server that the device has a self-configured
IPv6 address". Thanks.


>
> # 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.
>


I personally think that SVG in RFCs is the devil, and this is a hill that
I'm willing to die on… :-P


>
>
> 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 ?
>
>

Hmmmm… I'll need to talk to co-authors on the 'dst' address part — we want
to keep the diagram uncluttered, and I figured that it was well enough
implied (there is also the potential clutter of having to explain the relay
interaction in the diagram).

Propose removing 'code' from the first.

And, yes, there is a typo in ADD-REG-REPLY — well spotted.
Thanks!

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

Hmmm… good point, but I couldn't figure out a clean way to insert it
without making it unwieldy. How is "A server which is configured to support
the address registration mechanism MUST include this option in Reply
messages."?


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

Fair enough — I updated this to "The client MUST include the Client
Identifier option [RFC8415] in the ADDR-REG-INFORM message."


>
> s/L2/layer-2/
>
>

Ta! Done.


>
> Which address (MAC / IP) in `from spoofing other clients' addresses` ?
>
>
Proposed "prevent a client from spoofing other clients' MAC 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 ?
>
>
>
>
This, and the next few will need some discussion.


>
> # 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/
>
>

Good catch, done.


>
>
> # 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.
>


There was a fair bit of discussion in the WG on this, and I believe that
the consensus was to not — no matter what time gets selected, some set of
people disagreed. Much of this mechanism is "informational" / "best effort"
and, I think, the WG decided that the additional complexity wasn't worth
it… but these discussions were a long time in the past, and wide ranging,
so my co-authors can correct me if I'm mistaken.


>
> # Section 4.6
>
>
>
> Please expand and add a reference for PIO.
>

Ta! Done.


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


Good point - I think "Justification".


>
> What is meant by ` to match the another lifetime`?
>
>
>
> # Section 6
>
>
>
> Please expand DUID.
>

Thanks, done.


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

Thanks, done!


>
> s/ assigned/assigned/ ?
>


Thanks, done.

I've made a PR with the proposed fixes, and we should review / merge it
soon.
Thank you again,
W