Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6
draft-ietf-dhc-dhcpv6-opt-sntp-01

Sent follow-up message to Thomas and Alex to see if their discusses have been addressed:

To: Thomas Narten , Alex Zinin
From: Margaret Wasserman
Subject: draft-ietf-dhc-dhcpv6-opt-sntp-01.txt
Cc: Ralph Droms , vibhaska@cisco.com

Hi Thomas and Alex,

There is a new version of draft-ietf-dhc-dhcpv6-opt-sntp available that is intended to address your discuss comments.  You can find it at:

http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-sntp-01.txt

If this addresses your comments, could you please clear your discusses?  If not, please let us know what issues remain.

Vijay, thanks for getting this document out before the deadline.  Sorry for losing touch earlier, and I hope we'll be able to get this through this time.

Margaret

Sent prod to author:

To: vijayak@india.hp.com, Ralph Droms
From: Margaret Wasserman
Subject: draft-ietf-dhc-dhcpv6-opt-sntp-00.txt
Cc: Thomas Narten , Ralph Droms

Hi Vijay,

It has been 8 months since draft-ietf-dhc-dhcpv6-opt-sntp-00.txt was reviewed by the IESG, but the document has not been updated to address the blocking IESG comments (copied below).  I am confused by this, as the IESG comments were not particularly complex.  We even had a call with Harald where we agreed to the wording required to address his issue.

Is there a problem with updating this document?  Vijay, if you no longer have any time to spend on this effort, should Ralph look for someone else to carry this work forward?

Margaret

(included discusses and comments)

[Ballot discuss]
This document should specify whether or not SNTPv4 servers can be listed in the options list.
If they can, it should specify how they are listed.
If they cannot, it should say so; it would be beneficial to have it explain how a client with both IPv4 and IPv6 stacks decides which SNTP servers to use.

[Ballot discuss]
>    The Simple Network Time Protocol Servers option provides a list of
>    one or more IPv6 addresses of SNTP [3] servers available to the
>    client for synchronization. The SNTP servers SHOULD be listed in
>    the order of preference.

For interoperability, it would be better to say that clients MUST
processes the servers as if they were in priority order. Whether the
server takes advantage of that or not is an operational issue. But if
the clients aren't guaranteed to process them in order, there is
little point in the server putting them in order.

[Ballot comment]
From OPS DIrectorate (Pekka):

nits:
- spell out SNTP in the Abstract
- acknowledgement section should be split to a real acknowledgement
  section, and the regular ISOC funding acknowledgement.
- IPR statement could be added.
- add a dot at the end of the paragraph in section 2.

[Ballot discuss]
From OPS Directorate (Pekka):

Biggest concern:

- This I-D describes only SNTP.  Where are the options for NTP?  NTP is
  at least as important than SNTP.  I do not believe we should go
  forward with either until we know how we want to deal with both
  (e.g., one option which includes either, separate options in one I-D,
  separate options in two I-Ds)

Bigger issues:

                            The SNTP servers SHOULD be listed in
  the order of preference.

==> does a SHOULD make sense here?  e.g. in some other DHCPv6 option
specs, it is just "are listed in the order of preference".  Note that
the DHCP server does not necessarily even KNOW what is the order of
preference, unless the implementation is made so that it makes any
difference.

====
  option-code:  OPTION_SNTP_SERVERS (tbd)

  option-len:  Length of the 'SNTP server'  fields in octets; It must be
        a multiple of 16

  SNTP server:    IPv6 address of SNTP server
====
==> however, as the diagram above shows, by default the length is
NEVER (unless padded) a multiple of 16, and this document does not
describe what to do.  I guess it should say and depict in the figure
that a padding will be added.

  The option number for this option MAY appear in the Option Request
  Option [1] in the following messages:  Solicit, Request, Renew,
  Rebind, Information-Request and Reconfigure.

==> isn't this paragraph redundant and unnecessary?  RFC3315 governs
when you may use Option Request Option (AFAICS), and repeating this
here seems unnecessary.  And if ORO is included, you can of course
always include the SNTP option on the list of the options the client
wants to receive...