There are cases, for example when peer is requesting two DNS
addresses, but we can only give one, we should reject the secondary
DNS request first, before sending NAK to acceptable options.
Option parser can reject a parameter by returning -ENOTSUP and when
it wants to NAK the parameter, it returns -EINVAL.
On RFC 1661:
Configure-Reject
If some Configuration Options received in a Configure-Request are
not recognizable or are not acceptable for negotiation (as
configured by a network administrator), then the implementation
MUST transmit a Configure-Reject.
Configure-Nak
If every instance of the received Configuration Options is
recognizable, but some values are not acceptable, then the
implementation MUST transmit a Configure-Nak.
So as stated by RFC, we should start the negotiation by rejecting all
parameters that we cannot configure. I added an example of rejecting
DNS requests, if we don't have those.
Signed-off-by: Seppo Takalo <seppo.takalo@nordicsemi.no>
d5f4ca3b64