Understanding 'authoritative' in dhcpd.conf

From Support ticket #14997

We were surprised that when an ISC DHCP server does not have 'authoritative' set to yes an option (the default is no) that all DHCPINFORM messages are not responded to and the logs contain "not authoritative for subnet".

Reading the man page for dhcpd.conf, we see this explanation:

The authoritative statement

...

The DHCP server will normally assume that the configuration information about a given network segment is not known to be correct and is not authoritative. This is so that if a naive user installs a DHCP server not fully understanding how to configure it, it does not send spurious DHCPNAK messages to clients that have obtained addresses from a legitimate DHCP server on the network.

In other words, if there are clients out there that are going to be getting leases from other servers that ISC DHCP knows nothing about, and then trying to get additional options via DHCPINFORM, and you're not really sure that you've got your configuration correct, then not being authoritative is probably the right way to go...

Network administrators setting up authoritative DHCP servers for their networks should always write authoritative; at the top of their configuration file to indicate that the DHCP server should send DHCPNAK messages to misconfigured clients. If this is not done, clients will be unable to get a correct IP address after changing subnets until their old lease has expired, which could take quite a long time.

In other words, if you're certain that you're right and any clients sending DHCP messages to your servers for addresses that they shouldn't be, then being authoritative is correct.

=======

But not having your ISC DHCP server be authoritative, causes it not to respond to any DHCPINFORMs, rather than just those with which it has a problem. It stops the DHCPNAKs, but it also stops the DHCPACKs too.

=======

Is this something where the documentation could be cleared, or is it functionality that was not supposed to be this way?