[ntp:questions] What can be uses as an SNTP server (was: How to handle leap second condition correctly?)

David Woolley david at djwhome.demon.co.uk
Sun Jun 12 12:26:54 UTC 2005

In article <ywn9d5qs9vil.fsf at ntp1.isc.org>,
Harlan Stenn <stenn at ntp.isc.org> wrote:

> I just re-read the draft 2030 spec and it says that the legal values for

RFC 2030 is released.  It can't be a draft.  Any replacement will have
a new RFC number.  It will either obsolete RFC 2030 or define a new version
of the protocol.  (For example, the NTP v4 RFC, when it arrives, will not
obsolete RFC 1305.)

> Also, the draft SNTP RFC says:

Except for KOD, this is the same as RFC 2030.

>    2-15     secondary reference (synchronized by NTP or SNTP)

Although RFC 2030 doesn't use the proper SHOULD NOT style language, it is
clear to me that the only reasonable interpretation of the following is
SHOULD NOT, so the above is valid; an RFC 2030 server MAY operate at
stratum's higher than one and MAY exist.

   It is strongly recommended that SNTP be used only at the extremities
   of the synchronization subnet. SNTP clients should operate only at
   the leaves (highest stratum) of the subnet and in configurations
   where no NTP or SNTP client is dependent on another SNTP client for
   synchronization. SNTP servers should operate only at the root
   (stratum 1) of the subnet and then only in configurations where no
   other source of synchronization other than a reliable radio or modem
   time service is available. The full degree of reliability ordinarily

(Note that Windows always claims stratum 2, when synchronised, so is 
broken in its use of this field.)

>   1        primary reference (NTP or SNTP, synchronized, e.g., by radio clock)

A stratum one server is, by definition, never synchronised using NTP or SNTP;
you are confusing the wire protocol with the server implementation (something
that the NTP/SNTP distinction does, to some extent, itself).  Defining by
example is not good enough for a precise specification.

You may be proposing a new RFC.  In that case, I doubt that you can change
a SHOULD NOT into a MUST NOT without creating a new version of the protocol,
as I very much doubt that IETF likes retrospective legislation.  To get
your desired effect in a new version of the protocol, you would need to 
have something like:

   1        primary reference (this value SHALL only be used by
            <definition that doesn't depend on the use of "e.g.">)
   2-15     secondary reference (these values SHALL only be used by
            a server fully implementing NTP (RFCxxxx))

I'd note, though, that some significant aspects of NTP V3 are only
specified as an appendix, and are therefore probably non-normative,
so compliance with the NTP RFC is not the same as equivalence with xntpd.

Note that the above doesn't properly cover the increasingly standard use
of an unsynchronised local clock as a reference.  In particular, it forces
it to be configured as stratum 0.  As to even allowing the use of such
references, this has to be an area where SHOULD NOT has to be used.  Using
MUST NOT will just result in lots of non-compliant implementations without
making much real difference to the number of people actually doing it.

A better approach to local clocks (and SNTP) would be to have extra
protocol fields that signal that the server is not in a strict NTP mode.
I'd suggest it be bit coded, with one bit for not synchronised to UTC,
and one for other factors (including local reference clock or not the full
NTP algorithms).  The last part might be better decomposed with separate
bits for SNTP, local reference clock, and other.  Such bits would be
set in any transmitted packet traceable to an input one with them set.

This feature would probably be commercially unacceptable, though, and
probably wouldn't be too widely implemented, as it would cause apparent
failures when the customer felt they were in the right, and when other
implementations didn't fail.  In a world of people who demand solutions
and not counselling, implementing such restrictions can be commercial

This is especially true of SNTP.  Any attempt to change SHOULD NOT to
MUST NOT will be ignored, because SNTP is generally only used for reasons
of commercial expediency, and in such context, inconvenient rules will
always be ignored.

More information about the questions mailing list