Telechat Review of draft-ietf-ntp-dhcpv6-ntp-opt-
review-ietf-ntp-dhcpv6-ntp-opt-secdir-telechat-zorn-2009-08-27-00
Request | Review of | draft-ietf-ntp-dhcpv6-ntp-opt |
---|---|---|
Requested revision | No specific revision (document currently at 06) | |
Type | Telechat Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2009-08-25 | |
Requested | 2009-08-03 | |
Authors | Benoit Lourdelet , Richard Gayraud | |
I-D last updated | 2009-08-27 | |
Completed reviews |
Secdir Telechat review of -??
by Glen Zorn
|
|
Assignment | Reviewer | Glen Zorn |
State | Completed | |
Request | Telechat review on draft-ietf-ntp-dhcpv6-ntp-opt by Security Area Directorate Assigned | |
Completed | 2009-08-27 |
review-ietf-ntp-dhcpv6-ntp-opt-secdir-telechat-zorn-2009-08-27-00
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