Telechat Review of draft-ietf-ntp-dhcpv6-ntp-opt-
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
Global: s/an NTP/a NTP/
s/an FQDN/a FQDN/
In section 2., the acronym "DHCPv6" should be expanded on first usage.
The first paragraph of section 2.1 says:
When using DHCPv6 to offer NTP Server location, and if
there is a need to distribute a device with a hardcoded
configuration, this configuration MUST NOT include server location
that is not part of the organization that distribute this device.
s/distribute/distributes in the last line.
I don't understand what device is under discussion. Is it a DHCP server? A
DHCP client? Also,
Typical usage of this option is to specify an NTP Server that is part
of the organization that operates the DHCPv6 server.
This seems less clear than it should be to me; suggest rephrasing, perhaps
This option will typically be used by the organization operating the
server to provide data regarding the location of its own NTP server.
The second paragraph of section 2.1 says:
DNS can be used to redirect misconfigured clients
to an unexisting IPv6 address instead of having to change the address
of the NTP server itself.
I don't know exactly what an "unexisting IPv6 address" is, nor why it would
be a good thing to redirect misconfigured clients to one. Also, the acronym
"FQDN" should be expanded on first usage.
The third paragraph of section 2.1 says: "The DHCPv6 option for NTP is then
restricted to server location." This construction is a little bit clumsy, I
think; suggest changing to "The DHCPv6 option for NTP is therefore
restricted to server location."
In the first paragraph of section 3.0, the acronym "SNTP" should be expanded
upon first usage; suggest changing "This option serves as a container for
all the information related to one NTP server or SNTP server." to "This
option serves as a container for all the information related to one NTP or
Simple Network Time Protocol (SNTP) [RFC4335] server." This will also take
care of one of the unused references mentioned below.
The second paragraph of section 3.0 says:
While the FQDN option offers the most deployment
flexibility, resiliency as well as security, the IP address options
are defined to cover cases where a dependancy to DNS is not
I think that the readability of this sentence could be improved; suggest
While the FQDN option offers the most deployment Flexibility and
resiliency as well as security, the IP address options are defined
to cover cases where a DNS dependency is not desirable.
The last paragraph of section 3.0 says:
This document does not define any priority between the client's
embedded configuration and the NTP servers or SNTP servers discovered
via this option.
Suggest changing to
This document does not define any priority relationship between the
embedded configuration (if any) and the NTP or SNTP servers discovered
via this option.
In the heading of section 4, capitalize "use" or just change the heading
from "Examples of use" to "Examples".
Section 4 seems somewhat less than useful to me, especially since the
examples are inconsistent: the FQDN example uses the exact encoding of the
FQDN, but the unicast and multicast address examples do not. I suggest
either making the examples consistent by putting the actual address encoding
of the addresses in the address examples or just getting rid of section 4
The references to RFC 4075 and RFC 4330 are defined but never used.
Hope this helps.