I think the changes help a bit in the understanding the special nature of the dhcp daemon command. However, I think we can do better here. Adding that dhcp executable with daemon option is relaying messages back and forth between another DHCP server on the network and the client inside the container.

@venekamp thanks for the feedback! What you are describing above sounds like a DHCP proxy, but I don't think it is the case for the current plugin. This one should just register itself as a DHCP endpoint (client) and hand out the assigned network config via CNI semantics (paging @squeed just to confirm I'm not wrong here).

If the above statement is correct, I think it is better described as a "DHCP (host) agent" more than a daemon or a proxy.

Well, it's a dhcp client daemon. It's a bit more than a proxy; it also keeps the leases alive while the container is running.

My suggested wording would be:

The DHCP IPAM plugin needs a client daemon to be running on the host.

@lucab, @squeed My first understanding was that it was a fully operational DHCP server, then I thought it was a proxying client and now I understand it to be more than just relaying DHCP messages. I would try to clarify what this "thing" does and what it expects. My try would be:

The DHCP IPAM plugin acts as a proxy between a dhcp client running inside the container and a dhcp service already running on the network. At the same time the plugin keeps the leases alive while the container is running. It can do this, because it still has the appropriate capabilities set.

You can omit the last sentence. At least I think this is why the plugin can renew leases and such things, while processes inside the container do no-longer have the capabilities to make changes to the interface.

updated, ptal

I think it reads well.