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.



EDITORIAL

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
as 

  This option will typically be used by the organization operating the
DHCPv6 
  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
   desirable.

I think that the readability of this sentence could be improved; suggest
changing to 

   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
client's
   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
altogether.


The references to RFC 4075 and RFC 4330 are defined but never used.

Hope this helps.

~gwz