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

[Jen Linkova <[e-mail]>]

Hi Jim,

Thank you for your review!

On Wed, May 8, 2024 at 10:14 PM Jim Guichard via Datatracker
<[e-mail]> wrote:
> 141        address registration.  It can do this by including the Address
> 142        Registration option code the Option Request option (see Section 21.7
> 143        of [RFC8415]) of the Information-Request, Solicit, Request, Renew, or
>
> Jim> I find the above text a little confusing. RFC 8415 defines the ‘Option
> Request’ option with ‘option-code’. I think the above is saying that an
> ‘Address Registration’ option-code should be included in the ‘Option Request’
> option (?). If so, I suggest saying ‘It can do this by including the Address
> Registration option-code within the Option Request option (see Section 21.7 of
> [RFC8415]’

Yes, sorry, it was clearly a typo - Peter Yee pointed it out as well.
Will be fixed in the next version.

> 147        option in its Reply message.  If the network does not support (or is
> 148        not willing to receive) any address registration information, the
> 149        client MUST NOT register any addresses.  Otherwise, the client
> 150        registers addresses as described below.
>
> Jim> What happens if the client ignores the MUST NOT?

Well, the server will be receiving some packets it's not configured to process.
Do you want us to make it explicit that 'MUST NOT' is for preventing
some garbage traffic?

> 153        its interfaces, a client implementing this specification SHOULD
> 154        multicast an ADDR-REG-INFORM message in order to inform the DHCPv6
>
> Jim> Using which multicast address? It looks like you specify it in section 4.2
> so I would suggest referencing that here.

Will be added in the next revision, thank you!

-- 
Cheers, Jen Linkova