Re: [dhcwg] dhcpv6-24: Rapid Commit

> - A client should be able to send this option always if it supports
>    it.

Why even have a special option requesting it? It would be nice if the
client always did the same thing, with the servers (and how they are
configured) determining whether the Rapid Commit is enabled and to be
used. It seems odd to me that the  *client* decides when it wants the
Rapid Commit. Isn't the appropriateness of tihs determined by the
envirnment to which the client connects?

> - A client that receives a Reply to a Solicit w/Rapid Commit *may*
>   use that Reply. If it doesn't, it should send a Release.

Why not a MUST, not SHOULD? If the client requests a Rapid Commit, it
should be prepared to implement it fully.

> - A client must use the normal Solicit procedure and await multiple
>   Reply messages (and Advertises). If the client receives a Reply
>   and doesn't use the information, it must send a Release. If the
>   client receives no Reply messages or doesn't choose to use any, it
>   should then follow the Advertise handling as normal.

> The option does have a value at least from the server / server
> administrator standpoint. An administrator could select not to allow
> this if there are multiple servers in the configuration. If there is
> a single server (or single set of primary/backup type servers), a
> server can be configured to allow Rapid Commit.

This indicates to me this should be under server control, not client
(as in the client decides whether to request it).

Thomas

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg