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

From: "Richard Gayraud (rgayraud)" <[email-masked]>
Date: Tue, 26 Feb 2008 16:08:51 +0100

Hello Danny,

Thank you very much for your comments. Please see inline our reply.

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 ?

> 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.

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.

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.

_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Tue, 26 Feb 2008 12:58:42 -0500

> 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.

> capability. Another one is the use of sub-options that will enable

None of that really matters since you use whichever pieces you want to 
use at the receiving end.

> 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.

Please also see the latest NTP v4 draft just published: 
http://www.ietf.org/internet-drafts/draft-ietf-ntp-ntpv4-proto-09.txt

> 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 hope this clarifies matters.

Danny

---

From: "Richard Gayraud (rgayraud)" <[email-masked]>
Date: Wed, 27 Feb 2008 10:41:39 +0100

Hello Danny,

Thanks again for your interest. My comments are inline.

Regards,
Richard.

> True enough. NTPv3 did not officially support IPv6 though 
> that was not the reason for the major version change. I think 
> NTP is sufficient.
> 

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.

> 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 ?

---

From: Danny Mayer <[email-masked]>
Date: Wed, 27 Feb 2008 08:08:30 -0500

Hello Richard,

My comments also inline.

Danny

> the end, it really insists on the fact that it is about SNTP servers.

Had I been aware of it when it was being drafted, I would have objected 
to this since it doesn't make a lot of sense to advertise SNTP servers 
and I know of no list of public SNTP Servers. All of them run NTP, with 
the possible exception of Microsoft. I don't know what they run. At one 
time all of their Domain Controllers advertised stratum 2 which would be 
wrong for an SNTP server.

> of refclocks, Stratum-1 servers.

All of the public Stratum 1 servers run NTP rather than just SNTP. You 
can strip a bunch of code out to run SNTP but noone ever does that I am 
aware of. Microsoft may do something different but I have no idea what 
their code is doing.

> possible if nobody complains. But re-using the option number is at risk,

You know more about that area than I do so it's up to you. You can 
always let RFC 4075 die or obsolete it, but I don't see how it would be 
useful given that this draft would let any SNTP client use the same 
data. As I said before the real difference between SNTP and NTP is the 
algorithms used and not the on-wire protocol or usage of servers.  An 
NTP client (which is also a server) can also use SNTP Servers if they 
are available.

Danny