Network Time Protocol (NTP) Server Option for DHCPv6
draft-ietf-ntp-dhcpv6-ntp-opt-06

[Ballot comment]
I guess I can clear my Discuss as the new revision no longer Obsoletes RFC 4075. This seems a fairly significant change as it implies that both options could be equally supported, but I assume that this has been discussed and it is understood how migration to new implementations will be achieved.

[Ballot discuss]
A quick Discuss-Discuss that I hope the other ADs can address for me during the telechat...

What happens to the code point assigned by RFC 4075 if that RFC is obsoleted by this RFC, and this RFC does not take over the definition of that code point?

[Ballot comment]
3.3.  NTP Server FQDN Suboption

    FQDN: Fully Qualified Domain Name of the NTP server or SNTP server.
          This field MUST be encoded as described in [RFC3315],
          section 8.

I think this should be clearer that IDN names are not allowed here.

[Ballot discuss]
I only have a minor blocking comment on this document:

3.  NTP Server Option for DHCPv6

[...]

  The option itself does not contain any value.  Instead, it contains
  one or several suboptions that carry NTP server or SNTP server
  configuration information.  This option MUST include one, and only
  one, time source suboption.  The currently defined time source
  suboptions are: NTP_OPTION_SRV_ADDR, NTP_OPTION_SRV_MC_ADDR,
  NTP_OPTION_SRV_FQDN.  It carries the NTP server or SNTP server
  location, as a unicast or multicast IPv6 address or as an NTP server
  or SNTP server FQDN.  More time source suboptions may be defined in
  the future.

The last sentence implies that this needs a new IANA registry, but this registry is not defined in the document.

If there would be a new registry, IANA would like to know what the registration procedure would be.

[Ballot discuss]
It seems like a DHCP server may want to continue advertising 4075 style information as a transition strategy to this. I'd like to talk about if this should obsolete 4075

[Ballot comment]
I agree with Russ that this document should have a paragraph explaining
its relationship to RFC 4075 (which is being obsoleted by this
document), describing briefly why RFC 4075 is obsoleted (and what is
added here), and saying that the use of RFC 4075 is no longer
recommended.

Glen Zorn's SecDir review also identified a number of places that
would benefit from some clarification of the text, and provided
editorial comments that should be taken into account.

[Ballot discuss]
A quick Discuss-Discuss that I hope the other ADs can address for me during the telechat...

What happens to the code point assigned by RFC 4075 if that RFC is obsoleted by this RFC, and this RFC does not take over the definition of that code point?

[Ballot comment]
In addition to identifying items (2a) and (3) above, Glen Zorn's (late) secdir review dated
August 24 provides some suggested wording changes.  I would encourage the authors
to review Glen's suggestions and incorporate those that they find helpful.

[Ballot discuss]
There are three issues I would like to addressed before this document is published.

(1) This document is unclear with respect to the inclusion of other suboptions in addition
to the one and only one time source supotion.

Section 2.1 indicates that only server location will be included:

  While the NTP specification defines a comprehensive set of
  configuration parameters, modification of those parameters is best
  left to the decision of the client itself.  The DHCPv6 option for NTP
  is then restricted to server location.

Section 3 indicates that all configuration information related to an NTP
server will appear in suboptions, and implies that other suboptions
could appear (beyond time source).  From the first paragraph:

  This option serves as a container for all the information related to
  one NTP server or SNTP server.

From the second paragraph:

  The option itself does not contain any value.  Instead, it contains
  one or several suboptions that carry NTP server or SNTP server
  configuration information.  This option MUST include one, and only
  one, time source suboption.

Does the working group intend to limit the set of suboptions that can
appear to the time source suboptions, or is it just that this is the only
relevant suboption defined to date?

(2) There are two statements in section 2.1 that I could not wrap my brain
around. 

(2a) First, I had trouble with the second sentence of the first paragraph.  The first
two sentences are:

  The NTP service is publicly offered on the Internet by a number of
  organizations.  Those servers can be used but not abused, so any
  method which is tasked to disseminate locations of NTP Servers must
  act responsibly in a manner that does not lead to public server
  overloading. 

I actually believe that those servers *can* be abused, and that abuse may be hard
to correct with hardcoded configuration.  This option is designed to support
responsible use of thes public resources.  Is that what was meant here?

(2b) At the end of the second paragraph of section 2.1, the document states:

                              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.

What is an "unexisting IPv6 address"?

(3) In section 4, the FQDN example provides the exact encoding, but the unicast
and multicast examples do not provide the encoding for the addresses.  For consistency
and utility, the unicast and multicast examples should provide the exact encoding.

[Ballot discuss]
This document is unclear with respect to the inclusion of other suboptions in addition
to the one and only one time source supotion.

Section 2.1 indicates that only server location will be included:

  While the NTP specification defines a comprehensive set of
  configuration parameters, modification of those parameters is best
  left to the decision of the client itself.  The DHCPv6 option for NTP
  is then restricted to server location.

Section 3 indicates that all configuration information related to an NTP
server will appear in suboptions, and implies that other suboptions
could appear (beyond time source).  From the first paragraph:

  This option serves as a container for all the information related to
  one NTP server or SNTP server.

From the second paragraph:

  The option itself does not contain any value.  Instead, it contains
  one or several suboptions that carry NTP server or SNTP server
  configuration information.  This option MUST include one, and only
  one, time source suboption.

Does the working group intend to limit the set of suboptions that can
appear to the time source suboptions, or is it just that this is the only
relevant suboption defined to date?

(2) There are two statements in section 2.1 that I could not wrap my brain
around. 

First, I had trouble with the second sentence of the first paragraph.  The first
two sentences are:

  The NTP service is publicly offered on the Internet by a number of
  organizations.  Those servers can be used but not abused, so any
  method which is tasked to disseminate locations of NTP Servers must
  act responsibly in a manner that does not lead to public server
  overloading. 

I actually believe that those servers *can* be abused, and that abuse may be hard
to correct with hardcoded configuration.  This option is designed to support
responsible use of thes public resources.  Is that what was meant here?

At the end of the second paragraph of section 2.1, the document states:

                              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.

What is an "unexisting IPv6 address"?

(3)

[Ballot discuss]
This document will obsolete RFC 4075 (once approved).  Please help
  developers by including a section or appendix that summarizes the
  chnges from RFC 4075 to this document.

[Ballot comment]
3.3.  NTP Server FQDN Suboption

    FQDN: Fully Qualified Domain Name of the NTP server or SNTP server.
          This field MUST be encoded as described in [RFC3315],
          section 8.

I think this should be clearer that IDN names are not allowed here.

[Ballot discuss]
I only have a minor blocking comment on this document:

3.  NTP Server Option for DHCPv6

[...]

  The option itself does not contain any value.  Instead, it contains
  one or several suboptions that carry NTP server or SNTP server
  configuration information.  This option MUST include one, and only
  one, time source suboption.  The currently defined time source
  suboptions are: NTP_OPTION_SRV_ADDR, NTP_OPTION_SRV_MC_ADDR,
  NTP_OPTION_SRV_FQDN.  It carries the NTP server or SNTP server
  location, as a unicast or multicast IPv6 address or as an NTP server
  or SNTP server FQDN.  More time source suboptions may be defined in
  the future.

The last sentence implies that this needs a new IANA registry, but this registry is not defined in the document.

IANA questions/comments:

QUESTION: Is Action 2 correct? If so, it needs to be added to the
IANA Considerations section. We also need to know what the
registration procedures are and what the upper limit of registry
is.

Action 1:

Upon approval of this document, IANA will make the following
assignment in the "DHCP Option Codes" registry at
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

Value Description Reference
TBD OPTION_NTP_SERVER [RFC-ntp-dhcpv6-ntp-opt-04]


Action 2:

Upon approval of this document, IANA will create the following
sub-registry at
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

Registry Name: DHCP NTP server source options
Registration Procedures: ??

Initial contents of the sub-registry:

Value | Description | Reference
0 | Reserved | [RFC-ntp-dhcpv6-ntp-opt-04]
1 | NTP_OPTION_SRV_ADDR | [RFC-ntp-dhcpv6-ntp-opt-04]
2 | NTP_OPTION_SRV_MC_ADDR | [RFC-ntp-dhcpv6-ntp-opt-04]
3 | NTP_OPTION_SRV_FQDN | [RFC-ntp-dhcpv6-ntp-opt-04]
4-65534 | Unassigned |
65535 | Reserved | [RFC-ntp-dhcpv6-ntp-opt-04]

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Brian Haberman is the document shepherd for this document and he
believes this version is ready for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

Yes, this document has received adequate review from  both the NTP
and the DHC working groups.  The shepherd has no concerns about those
reviews.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No concerns.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No concerns.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

The WG as a whole understands and agrees with the document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

This document has two ID nits warnings which can be resolved with either
an edit made for IETF Last Call comments or as an RFC Editor note.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The references are formated correctly.  It has normative references
to two other NTP WG document drafts which are already under IESG
Review.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations section exists and is consistent with the request
made in the body of the document.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

N/A.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        This document defines a DHCPv6 option and associated suboptions
        to provide Network Time Protocol version 4 or greater
        configuration information to DHCPv6 hosts.

    Working Group Summary
        This document has received in-depth review from both the NTP
        and DHC working groups and has strong support for advancement.