Re: WGLC for draft-ietf-dhc-addr-notification - Respond by December 11, 2023

My only worry about this is that the draft (correctly) acknowledges that
there may be more than one DHCP server and that such servers may have
different answers to the registration question, but doesn't talk about the
specifics of when the client decides that things have or have not changed.
The only message for which RFC8415 acknowledges that there can be multiple
replies is a Solicit, but in fact an Information-Request could just as
easily return multiple replies. I don't know if the WG is thinking about
this, but this seems like a fairly serious gap.

So I think that in fact what you're proposing here isn't quite right.
Rather, the client in this case should wait as it does for Advertises. When
it gets a reply that allows for registration, it registers with that
server. If it gets no reply that allows for registration, then it stops
registering. This behavior should be specified in 8415-bis, not in this
document.  Additionally, the client should pick a server, and include the
server's DUID in a server identifier option as specified in section 14 of
8415. So this is the opposite of what's currently specified. The reason for
this is that if you have some servers that support address registration,
and some that do not, and you send an address registration message without
specifying a server identifier, it's going to be processed by all servers,
so you'll get errors back from servers that don't support it and possibly
multiple acknowledgments from multiple servers (maybe that's okay though?).

Anyway, I think this needs a bit more thinking.

On Mon, Dec 4, 2023 at 5:24 PM Jen Linkova <[email protected]> wrote:

> The WGLC has been uncomfortably quiet, so we've just submitted -07
> (https://www.ietf.org/archive/id/draft-ietf-dhc-addr-notification-07.html)
> to address an oscillation problem: if some servers support the
> registration and some don't, the client might turn the registration on
> and off, depending on the order of arriving Replies.
> While it's not the end of the world, I think it's rather undesirable.
> The new text says that the client always register if at least one
> server returns the OPTION_ADDR_REG_ENABLE option, and say the client
> MUST stop
> registering if that server stops returning the option.
> Basically, as long as at least one server supports the registration,
> the client will be sending messages, but it's still possible for the
> administrator to turn the registration off.
>
> Comments?
>
> On Mon, Nov 27, 2023 at 9:32 PM Timothy Winters <[email protected]> wrote:
> >
> > Hi:
> >
> > The authors believe this document is ready for WGLC. Therefore, the
> chairs
> > are initiating a WGLC on this document.
> >
> > Please review this document and provide your comments and whether you
> > support this document moving forward or not by the end of day on Monday,
> > December 11th, 2023.
> >
> > Please see
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-dhc-addr-notification-06.
> >
> > This is a Standards Track document.
> >
> > Thank you!
> >   ~ Tim and Bernie
> > _______________________________________________
> > dhcwg mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>
> --
> Cheers, Jen Linkova
>
> _______________________________________________
> dhcwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

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