Hello,
I took a quick look at draft-ietf-dhc-option-guidelines-14. In Section 8:
"FQDN imposes a number of additional failure modes and issues that
should be dealt with:
1. The client must have a knowledge about available DNS servers.
That typically means that option DNS_SERVERS is mandatory. This
should be mentioned in the draft that defines new option. It is
possible that the server will return FQDN option, but not the DNS
Servers option. There should be a brief discussion about it;
2. The DNS may not be reachable;
3. DNS may be available, but may not have appropriate information
(e.g. no AAAA records for specified FQDN);"
The draft recommends using IP addresses unless there is a good reason
to use an FQDN. I understand that everything breaks when a FQDN
cannot be resolved. One of the principles which is not usually
mentioned nowadays ia that "user applications should use names rather
than addresses". I'll comment quickly about the above points.
The client would have to perform DNS resolution (Item 1) for the
system to work. There are cases where one can get away with using IP
addresses.
When the DNS is not reachable (Item 2) people complain. One of the
arguments for redundancy is that the network will keep working if a
system fails. A person would usually see that there is some DNS
service which is reachable.
Item 3 is odd. The person putting in the appropriate information
would have to think about whether the network will support, for
example, IPv6-only hosts.
In Section 9:
"There is no such ambiguity in DHCPv6 (with the unfortunate exception
of [RFC5908],which was published without following the advice provided
during the DHC working group review, and contains many errors."
This sounds like a case of a working group doing work which is not
part of its charter (see https://datatracker.ietf.org/wg/ntp/charter/
). The approval message mentioned that "This document has received
in-depth review from both the NTP and DHC working groups and has
strong support for advancement". Anyway, the above text does not
sound politically correct. :-)
Section 13 discusses about chartering requirements and advice for
Responsible ADs. I don't think that it belongs in a document about
guidance to prospective DHCPv6 Option developers.
Section 22 provides advice about updating existing RFCs. I don't
think that it belongs in a document about DHCPv6 Option guidelines.
There is advice for authors of drafts in the Security Considerations
section. I'll assume that authors are a security risk. :-)
Regards,
-sm