[dhcwg] Re: Roman Danyliw's No Objection on draft-ietf-dhc-addr-notification-11: (with COMMENT)

[Jen Linkova <[e-mail]>]

Hi Roman,

Thank you for reviewing the draft!

On Mon, May 13, 2024 at 12:15 AM Roman Danyliw via Datatracker
<[e-mail]> wrote:
> ** Section 4.2.1
>
>    *  SHOULD log the address registration information (as is done
>       normally for clients to which it has assigned an address), unless
>       configured not to do so.  The server SHOULD log the client DUID
>       and the link-layer address, if available.  The server MAY log any
>       other information.
>
> Section 1 elaborated on forensic and security use cases as key motivations for
> this protocol feature.  If a log entry is not made for the registration as
> allowed by this SHOULD, most of the value of this feature seems to be lost.

Well, the beneficiary of the feature controls the server, so if they
for some reason do not want the server to log that - it's their
choice.
If the server violates this requirement, there is no negative impact
to the implementation, the network, or other devices, hence we chose
'SHOULD'.
Also, I'm sure we can imagine some corner cases when the server would
have a legitimate reason not to log smth, so I'm a bit afraid of
putting MUST here.
One of the options might be replacing the fist SHOULD with MUST seems
to be harmless, as there is a 'unless configured not to do so' safety
net.
(I'm thinking about a case when there are multiple servers on the
network and the administrator might want different logging behaviour
from them).

> ** Section 7. Editorial.
>
>    *  one new DHCPv6 option, described in Section 4.1 which requires an
>       allocation out of the registry of DHCPv6 Option Codes:
>
> Technically, the registry name is “Option Codes”
>
> ** Section 7:  Editorial. Please state the obvious that the reference column is
> this document for the two mentioned registries.

Thanks for catching this. Will be fixed in -13 (sorry, missed your
email while submitting -12 ;(

--
Cheers, Jen Linkova