[ntpwg] [dhcwg] NTP option for DHCPv6 [draft-gayraud-dhcpv6-ntp-opt-01.txt] posted

[Richard Gayraud (rgayraud)]

Hello Danny,

Thanks again for your interest. My comments are inline.

Regards,
Richard.

> > Danny Mayer (mayer at ntp.isc.org) wrote:
> > > Well my first question is why are you calling out NTPv4? Will 
> > > it break if it's v5? If so it's flawed. If not that should be 
> > > removed.
> > 
> > I think you are right. Do you think we should call out for "NTPv4 
> > or higher version", or simply "NTP" ? Given that this is running 
> > only on IPv6, so by definition, only for NTP >= 4 ?
> > 
> 
> True enough. NTPv3 did not officially support IPv6 though 
> that was not the reason for the major version change. I think 
> NTP is sufficient.
> 
> > > Second, how does this differ from the SNTP options in 
> > > RFC4075? Is there a reason that you know of that requires 
> > > that they be separate options? I can see no reason for both.
> > >
> > > Danny
> >  
> > This differs from SNTP options by various things. One is the FQDN
> > capability. Another one is the use of sub-options that will enable
> > easier extendability.
> > 
> 
> None of that really matters since you use whichever pieces 
> you want to 
> use at the receiving end.
> 
> > But, the main point is the fact that RFC4075 advertise SNTP servers,
> > which are, by definition stratum-1 servers. This is not suitable
> > for the common case of client workstations on a LAN. Doing so would 
> > imply that these LANs would all have a local stratum-1 server.
> > 
> 
> That's a misconception on the part of the authors of RFC4075. The 
> current SNTP RFC 4330 talks about SNTP Servers being required to be 
> Stratum 1 servers but says nothing about SNTP clients needing to use 
> them. RFC 4075 and this draft is about the clients rather than the 
> servers. An SNTP Client can use any SNTP server or NTP server of any 
> stratum without limits (except for policy limits). 
> Furthermore there is 
> no difference in the on-the-wire packets of an SNTP client or server 
> from a NTP client or server. The stratum of the client becomes one 
> greater than the stratum of the server chosen by the NTP algorithms.

We are in line regarding all this. However, RFC4075 clearly states 
that it advertizes a list of SNTP _Servers_. From the abstract to 
the end, it really insists on the fact that it is about SNTP servers.

This makes it really ambigous... Or, if you read it the rigorous way, 
this makes it really clear that its intend was to advertize the location

of refclocks, Stratum-1 servers.

> Please also see the latest NTP v4 draft just published: 
> http://www.ietf.org/internet-drafts/draft-ietf-ntp-ntpv4-proto-09.txt
> 
> > This looks like a mistake in 4075, both in wording and intend. One
> > may want to deprecate 4075, but some people said at the last IETF 
> > that it could be of some use if someone wants to advertise SNTP 
> > stratum-1 servers via DHCP.
> 
> I recommend deprecating RFC 4075 and replacing it with this one and 
> reusing the option numbers and updating the IANA 
> registrations of those options to include NTP.

I would be in favor of that... But I'm afraid this is not an option, as
we are not binary-compatible with OPTION_SNTP_SERVERS defined in 4075. 
I don't want to break any existing implementation. Deprecating is 
possible if nobody complains. But re-using the option number is at risk,
don't you think so ?

> I hope this clarifies matters.
> 
> Danny