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

[Danny Mayer]

Hello Richard,

My comments also inline.

Danny

Richard Gayraud (rgayraud) wrote:
> 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.
> 

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.

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

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.

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

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

>> I hope this clarifies matters.
>>
>> Danny
>