Subject: [ntpwg] ***SPAM*** FW: Comments on NTP draft -06

From: karen.odonoghue at navy.mil (Odonoghue, Karen F CIV NSWCDD, W13)
Date: Tue, 26 Jun 2007 22:52:28 -0500

This message from Stewart seems to have been bounced by 
the ntp mailing list as spam. 

Karen

-----Original Message-----
From: Stewart Bryant [mailto:stbryant at cisco.com] 
Sent: Tuesday, June 26, 2007 8:48
To: Odonoghue, Karen F CIV NSWCDD, W13
Cc: NTP Working Group
Subject: Comments on NTP draft -06

Abstract

   The Network Time Protocol (NTP) is widely used to synchronize
   computer clocks in the Internet.  This document describes NTP Version
   4 (NTPv4), which is backwards compatible with NTP Version 3 (NTPv3)
   described in RFC 1305, as well as previous versions of the protocol.
   It includes a modified protocol header to accommodate the Internet
SB> What does "It" refer to?
   Protocol Version 6 address family.  NTPv4 includes fundamental

==========

   The NTP subnet model includes a number of widely accessible primary
   time servers synchronized by wire or radio to national standards.
   The purpose of the NTP protocol is to convey timekeeping information
   from these primary servers to secondary time servers and clients via
   both private networks and the public Internet.  Crafted algorithms

SB> What is a crafted algorithm?

   mitigate errors that may result from network disruptions, server
   failures and possible hostile actions.  Servers and clients are
   configured such that values flow towards clients from the primary
   servers at the root via branching secondary servers.

=========

2.  Modes of Operation

   An NTP implementation operates as a primary server, secondary server
   or client.  A primary server is synchronized directly to a reference
   clock, such as a GPS receiver or telephone modem service.  A client
   synchronizes to one or more upstream servers, but does not provide
   synchronization to dependent clients.  A secondary server has one or
   more upstream servers and one or more downstream servers or clients.
   All servers and clients who are fully NTPv4 compliance MUST implement
   the entire suite of algorithms described in this document.

SB> Why do we insist on this, surely someone producing an improved
SB> algorithm should be able to use it and still claim conformance?

=========

   As a standard practice, timing network topology should be organized
SB> Should or MUST?
   to avoid timing loops and minimize the synchronization distance.  In
   NTP the subnet topology is determined using a variant of the Bellman-
   Ford distributed routing algorithm, which computes the shortest-
   distance spanning tree rooted on the primary servers.  As a result of
SB> check the term spanning - shortest path tree might be better
SB> Do you mean server (singular) or servers (plural). If the latter
there
SB> may be a collection of SPTs rooted at each server
   this design, the algorithm automatically reorganizes the subnet, so
   as to produce the most accurate and reliable time, even when there
   are failures in the timing network.

============

                   +-----------------------------------+
                   | Packet Variable <--   Variable    |
                   +-----------------------------------+
                   | x.leap        <--     s.leap      |
                   | x.version     <--     r.version   |
                   | x.mode        <--     4           |
                   | x.stratum     <--     s.stratum   |
                   | x.poll        <--     r.poll      |
                   | x.precision   <--     s.precision |
                   | x.rootdelay   <--     s.rootdelay |
                   | x.rootdisp    <--     s.rootdisp  |
                   | x.refid       <--     s.refid     |
                   | x.reftime     <--     s.reftime   |
                   | x.org         <--     r.xmt       |
                   | x.rec         <--     r.dst       |
                   | x.xmt         <--     clock       |
                   | x.keyid       <--     r.keyid     |
                   | x.digest      <--     md5 digest  |
                   +-----------------------------------+

                     Figure 2: fast_xmit Packet Header

SB> This is not a header definition in an IETF sense. In any case this
SB> seems rather detailed this early in the spec given that no
definition
SB> of these fields is yet given.

============

   The ephemeral associations compete among themselves.  As new
   ephemeral associations are mobilized, the client runs the mitigation
   algorithms described in Section 10 and Section 11.2 for the best
   candidates out of the population, the remaining ephemeral
   associations are timed out and demobilized.  In this way the
   population includes only the best and freshest candidates to
SB> Freshest??
   discipline the system clock.  The reference implementation includes
   intricate means to do this, but these are beyond the scope of this
   document.

==========
   The delay (delta) represents the round trip delay
   between the client and server.  The dispersion (epsilon) represents
   the maximum error inherent in the measurement.  It increases at a
SB> Shouldn't the term "maximum error" have some form of statistical 
context?
   rate equal to the maximum disciplined system clock frequency
   tolerance (PHI), typically 15 PPM.  The jitter (psi) is defined as
   the root-mean-square (RMS) average of the most recent offset
   differences, represents the nominal error in estimating the offset.
SB> In timing terms jitter has significance in representing the high
SB> frequency error term (as opposed to wander it's low frequency 
counterpart
SB> Do we need to make it clear that we are using a different
definition.

   While the theta, delta, epsilon, and psi statistics represent
   measurements of the system clock relative to the each server clock
SB> typo "to the each"

=========

   .....................................................................
   . Remote   .   Peer/Poll  .              System          .  Clock   .
   . Servers  .   Processes  .              Process         .Discipline.
   .          .              .                              . Process  .
   .+--------+. +-----------+. +------------+               .          .
   .|        |->|           |. |            |               .          .
   .|Server 1|  |Peer/Poll 1|->|            |               .          .
   .|        |<-|           |. |            |               .          .
   .+--------+. +-----------+. |            |               .          .
   .          .       ^      . |            |               .          .
   .          .       |      . |            |               .          .
   .+--------+. +-----------+. |            |  +-----------+.          .
   .|        |->|           |. | Selection  |->|           |. +------+ .
   .|Server 2|  |Peer/Poll 2|->|    and     |  | Combine   |->| Loop | .
   .|        |<-|           |. | Cluster    |  | Algorithm |. |Filter| .
   .+--------+. +-----------+. | Algorithms |->|           |. +------+ .
   .          .       ^      . |            |  +-----------+.    |     .
   .          .       |      . |            |               .    |     .
   .+--------+. +-----------+. |            |               .    |     .
   .|        |->|           |. |            |               .    |     .
   .|Server 3|  |Peer/Poll 3|->|            |               .    |     .
   .|        |<-|           |. |            |               .    |     .
   .+--------+. +-----------+. +------------+               .    |     .
   ....................^.........................................|......
                       |                                    .    V     .
                       |                                    . +-----+  .
                       +--------------------------------------| VFO |  .
                                                            . +-----+  .
                                                            .  Clock   .
                                                            .  Adjust  .
                                                            .  Process .
                                                            ............

                      Figure 3: Implementation Model

SB> Are three instances the norm, the max or just an example?

==========

   The only arithmetic operation permitted on dates and timestamps is

   twos-complement subtraction, yielding a 127-bit or 63-bit signed
SB> Why not addition to yield a time in the future?

===========

   s = era * 2^(32) + timestamp.

   Converting between NTP and system time can be a little messy, but
SB> but or and?
   beyond the scope of this document.  Note that the number of days in

===========

7.  Data Structures

   The NTP protocol state machines described in following sections are
SB>typo in the following
   defined using state variables and code fragments defined in
   Appendix A.  State variables are separated into classes according to
   their function in packet headers, peer and poll processes, the system
   process and the clock discipline process.  Packet variables represent
   the NTP header values in transmitted and received packets.  Peer and
   poll variables represent the contents of the association for each
   server separately.  System variables represent the state of the
   server as seen by its dependent clients.  Clock discipline variables
SB> what is a dependent client?
   represent the internal workings of the clock discipline algorithm.
   Additional parameters and variable classes are defined in Appendix A.

==========

            +-----------+-------+----------------------------------+
            | Name      | Value | Description                      |
            +-----------+-------+----------------------------------+
            | PORT      | 123   | NTP port number                  |
SB> UDP port number assigned to NTP?
SB> BTW can you run NTP over DCP or perhaps one of the SCTP modes?

==========

               +-----------+------------+-----------------------+
               | Name      | Formula    | Description           |
               +-----------+------------+-----------------------+
               | leap      | leap       | leap indicator (LI)   |
               | version   | version    | version number (VN)   |
               | mode      | mode       | mode                  |
               | stratum   | stratum    | stratum               |
               | poll      | poll       | poll exponent         |
               | precision | rho        | precision exponent    |
               | rootdelay | delta_r    | root delay            |
               | rootdisp  | epsilon_r  | root dispersion       |
               | refid     | refid      | reference ID          |
               | reftime   | reftime    | reference timestamp   |
               | org       | T1         | origin timestamp      |
               | rec       | T2         | receive timestamp     |
               | xmt       | T3         | transmit timestamp    |
               | dst       | T4         | destination timestamp |
               | keyid     | keyid      | key ID                |
               | digest    | digest     | message digest        |
               +-----------+------------+-----------------------+

SB> do you mean formula or symbol - applies many places - but we meet it
SB> here without explanation?

                     Figure 8: Packet Header Variables

   The NTP packet header follows the UDP and IP headers and the physical
   header specific to the underlying transport network.  Some fields use
   multiple words and others are packed in smaller fields within a word.
SB> I don't remember seeing a definition of word yet? In any case
SB> don't we mean longword?
   The NTP packet header shown in Figure 9 has 12 words followed by
   optional extension fields and finally an optional message
   authentication code (MAC) consisting of the key identifier field and
   message digest field.
SB> It should be clearer (in the fig) which of the (long)words  below
   are each component mentioned by name above.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |LI | VN  |Mode |    Stratum     |     Poll      |  Precision   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Root Delay                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Root Dispersion                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Reference ID                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                     Reference Timestamp (64)                  +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Origin Timestamp (64)                    +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Receive Timestamp (64)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Transmit Timestamp (64)                  +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    Extension Field 1 (variable)               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    Extension Field 2 (variable)               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Key Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                       Message Digest (128)                    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 9: Packet Header Format

===========

   The extension fields are used to add optional capabilities, for
   example, the Autokey security protocol [3].  The extension field
   format is presented in order that the packet can be parsed without
   knowledge of the extension field functions.  The MAC is used by both

Burbank, et al.         Expires November 25, 2007              [Page 20]

Internet-Draft             NTPv4 Specification                  May 2007

   Autokey and the symmetric key authentication scheme described in
   Appendix A.

   A list of the packet header variables is shown in Figure 8 and
   described in detail below.  Except for a minor variation when using
   the IPv6 address family, these fields are backwards compatible with
   NTPv3.  The packet header fields apply to both transmitted packets (x
   prefix) and received packets (r prefix).  In Figure 9 the size of
   some multiple-word fields is shown in bits if not the default 32
   bits. 
SB> Why not say bits in the fig and remove the text above which is
SB> mildly confusing

   The header extends from the beginning of the packet to the end
   of the Transmit Timestamp field.

SB> This would certainly be clearer with notations in the fig above
SB> or a set of smaller figures and a larger structure diagram
SB> or a better representation method such as pdf :)

   The fields and associated packet variables (in parentheses) are
   interpreted as follows:

   LI Leap Indicator (leap): 2-bit integer warning of an impending leap
   second to be inserted or deleted in the last minute of the current
   month with values defined in Figure 10.

           +-------+-------------------------------------------------+
           | Value | Meaning                                         |
           +-------+-------------------------------------------------+
           | 0     | no warning                                      |
           | 1     | last minute of the day has 61 seconds           |
           | 2     | last minute of the day has 59 seconds           |
SB> surely last minute of the last day of the month has X seconds?
           | 3     | alarm condition (the clock is not synchronized) |
           +-------+-------------------------------------------------+

===========

   It is customary to map the stratum value 0 in received packets to
   MAXSTRAT (16) in the peer variable p.stratum and to map p.stratum
   values of MAXSTRAT or greater to 0 in transmitted packets.  This
   allows reference clocks, which normally appear at stratum 0, to be
   conveniently mitigated using the same algorithms used for external
   sources.

SB> I do not understand the above para

   Poll: 8-bit signed integer representing the maximum interval between
   successive messages, in log2 seconds.  Suggested default limits for
   minimum and maximum poll intervals are 6 and 10, respectively.

   Precision: 8-bit signed integer representing the precision of the
   system clock, in log2 seconds.  For instance a value of -18
   corresponds to a precision of about one microsecond.  The precision
   can be determined when the service first starts up as the minimum
   time of several iterations to read the system clock.
SB> I do not understand the last sentence

===============
     +------+----------------------------------------------------------+
     | ID   | Clock Source                                             |
     +------+----------------------------------------------------------+
     | GOES | Geosynchronous Orbit Environment Satellite               |
     | GPS  | Global Position System                                   |
     | GAL  | Galileo Positioning System                               |
     | PPS  | Generic pulse-per-second                                 |
     | IRIG | Inter-Range Instrumentation Group                        |
     | WWVB | LF Radio WWVB Ft. Collins, CO 60 kHz                     |
     | DCF  | LF Radio DCF77 Mainflingen, DE 77.5 kHz                  |
     | HBG  | LF Radio HBG Prangins, HB 75 kHz                         |
     | MSF  | LF Radio MSF Anthorn, UK 60 kHz (Rugby until April 2007) |
     | JJY  | LF Radio JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz       |
     | LORC | MF Radio LORAN C 100 kHz                                 |
     | TDF  | MF Radio Allouis, FR 162 kHz                             |
     | CHU  | HF Radio CHU Ottawa, Ontario                             |
     | WWV  | HF Radio WWV Ft. Collins, CO                             |
     | WWVH | HF Radio WWVH Kauai, HI                                  |
     | NIST | NIST telephone modem                                     |
     | ACTS | NIST telephone modem                                     |
     | USNO | USNO telephone modem                                     |
     | PTB  | European telephone modem                                 |
     +------+----------------------------------------------------------+

                     Figure 13: Reference Identifiers

SB> Is this going to be an IANA registry?
SB> Does there need to be an IEEE1588 code?

=============

   Origin Timestamp (org): Time at the client when the request departed
   for the server, in NTP timestamp format.

SB>Is there a reference interface point for this?

=============

   The MAC consists of the Key Identifier followed by the Message
   Digest.  The message digest, or cryptosum, is calculated as in [8]
   over all header and optional extension fields, but not the MAC
   itself.

SB> All headers, or all NTP headers?

=============

   A list of
   the currently-defined kiss codes is given in Figure 14.  Other than
   displaying the kiss code, KoD packets have no protocol significance
   and are discarded after inspection.

SB> Is this going to be an IANA registry?

   +------+------------------------------------------------------------+
   | Code |                           Meaning                          |
   +------+------------------------------------------------------------+
   | ACST | The association belongs to a unicast server                |
   | AUTH | Server authentication failed                               |
   | AUTO | Autokey sequence failed                                    |
   | BCST | The association belongs to a broadcast server              |
   | CRYP | Cryptographic authentication or identification failed      |
   | DENY | Access denied by remote server                             |
   | DROP | Lost peer in symmetric mode                                |
   | RSTR | Access denied due to local policy                          |
   | INIT | The association has not yet synchronized for the first     |
   |      | time                                                       |
   | MCST | The association belongs to a dynamically discovered server |
   | NKEY | No key found. Either the key was never installed or is     |
   |      | not trusted                                                |
   | RATE | Rate exceeded. The server has temporarily denied access    |
   |      | because the client exceeded the rate threshold             |
   | RMOT | Alteration of association from a remote host running       |
   |      | ntpdc.                                                     |
   | STEP | A step change in system time has occurred, but the         |
   |      | association has not yet resynchronized                     |
   +------+------------------------------------------------------------+

                           Figure 14: Kiss Codes
===========

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Field Type           |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Association ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Filestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Value Length                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                            Value                              .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Signature Length                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                          Signature                            .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Padding (as needed)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 15: Extension Field Format

   All extension fields are zero-padded to a word (4 octets) boundary.
SB> Is it normal to describe words as 32 bits?

   The Field Type field is specific to the defined function and is not
   elaborated here.  While the minimum field length containing required
   fields is 4 words (16 octets), a maximum field length remains to be
   established.

   The Length field is a 16-bit integer which indicates the length of
SB> Integer or unsigned integer?

==========

   Note that the quantities within parentheses are computed from 64-bit
   unsigned timestamps and result in signed values with 63 significant
   bits plus sign.  These values can represent dates from 68 years in
   the past to 68 years in the future.  However, the offset and delay
   are computed as sums and differences of these values, which contain
   62 significant bits and two sign bits, so can represent unambiguous
   values from 34 years in the past to 34 years in the future.  In other
   words, the time of the client must be set within 34 years of the
   server before the service is started.  This is a fundamental
   limitation with 64-bit integer arithmetic.

SB> I am not sure why a client needs to be configured with a time
SB> to within 34 years. Surely if you make the assumption that the
SB> packet takes less than 34 years to arrive you can bootstrap
SB> without needing configuration - or at least you can relax the time
SB> from 34 years to 136 years

============

   In implementations where floating double arithmetic is available, the
   first-order differences can be converted to floating double and the
   second-order sums and differences computed in that arithmetic.  Since
   the second-order terms are typically very small relative to the
   timestamp magnitudes, there is no loss in significance, yet the
   unambiguous range is restored from 34 years to 68 years.

SB> Surely there is a protocol action that can resolve the ambiguity
SB> without needing floating double?

==============

   Note that the on-wire protocol as described resists replay of a
   server response packet.  However, it does not resist replay of the
   client request packet, which would result in a server reply packet
   with new values of T2 and T3 and result in incorrect offset and
   delay.  This vulnerability can be avoided by setting the xmt state
   variable to zero after computing the offset and delay.

SB> Need to check that the security section has a back ref to here.

==============

14.  Security Considerations

   NTPv4 provides an optional authentication field that utilizes the MD5
   algorithm.  MD5, as the case for SHA-1, is derived from MD4, which
   has long been known to be weak.  In 2004, techniques for efficiently
   finding collisions in MD5 were announced.  A summary of the
   apropriateness of MD5 can be found in [10].

   In the case of NTP as specified herein, NTP broadcast clients are
   vulnerable to disruption by misbehaving or hostile SNTP or NTP
   broadcast servers elsewhere in the Internet.  Access controls and/or
   cryptographic authentication means should be provided for additional
   security in such cases.

SB> This should be reviewed by the security directorate before the
SB> draft goes any further. Based on previous experience I doubt that
SB> the analysis will be considered sufficient. Note that the main
SB> text calls up at least one threat that is not called up here.

===============

15.  IANA Considerations

   UDP/TCP Port 123 was previously assigned by IANA for this protocol.
   The IANA has assigned the IPv4 multicast group address 224.0.1.1 and
   the IPv6 multicast address ending :101 for NTP.  This document
   introduces NTP extension fields allowing for the development of
   future extensions to the protocol, where a particular extension is to
   be identified by the Field Type sub-field within the extension field.
   IANA is requested to establish and maintain a registry for Extension
   Field Types associated with this protocol, populating this registry
   with no initial entries.  As future needs arise, new Extension Field
   Types may be defined.  Following the policies outlined in [11], new
   consensus.

SB> English problem in last sentence.

SB> There are a bunch of other values that are assigned in this protocol
SB> surely these need registries to ensure that the standard develops
SB> in a controlled way. This is an essential difference between
SB> definition by standard and definition by reference implementation.

============

Appendix A.  Code Skeleton

SB> You need to specify the normative/informative status of this
appendix
SB> vis a vis the main body of the specification.

SB> Shouldn't this have a reference to ANSI C so that we have a
SB> definition of all the types - alternatively they all
SB> need to be defined here for consistency.

=============

#include <math.h>               /* avoids complaints about sqrt() */
#include <sys/time.h>           /* for gettimeofday() and friends */
#include <stdlib.h>             /* for malloc() and friends */

SB> Don't you need a pointer to a definitive instance of the above
SB> header files?

/*
 * Data types
 *
 * This program assumes the int data type is 32 bitsand the long data
SB> typo bitsand

==============

/*
 * Timestamp conversion macroni
 */
SB> typo macroni?

============

/*
 * Global constants. Some of these might be converted to variables
 * which can be tinkered by configuration or computed on-fly. For
 * instance, the reference implementation computes PRECISION on-fly and
 * provides performance tuning for the defines marked with % below.
 */

SB> We really need to distinguish quite firmly between
SB> invariants, implementation parameters and initial values
SB> This comment applies to all of the #defines in the
SB> following sections

#define VERSION         4       /* version number */
#define MINDISP         .01     /* % minimum dispersion (s) */
#define MAXDISP         16      /* maximum dispersion (s) */
#define MAXDIST         1       /* % distance threshold (s) */
#define NOSYNC          0x3     /* leap unsync */
#define MAXSTRAT        16      /* maximum stratum (infinity metric) */
#define MINPOLL         6       /* % minimum poll interval (64 s)*/
#define MAXPOLL         17      /* % maximum poll interval (36.4 h) */
#define MINCLOCK        3       /* minimum manycast survivors */
#define MAXCLOCK        10      /* maximum manycast candidates */
#define TTLMAX          8       /* max ttl manycast */
#define BEACON          15      /* max interval between beacons */

#define PHI             15e-6   /* % frequency tolerance (15 PPM) */
#define NSTAGE          8       /* clock register stages */
#define NMAX            50      /* maximum number of peers */
#define NSANE           1       /* % minimum intersection survivors */
#define NMIN            3       /* % minimum cluster survivors */

===============

SB> Suppose you ought to point out that this is the UNIX epoch - NTP
SB> epoch difference
#define JAN_1970        2208988800UL /* 1970 - 1900 in seconds */

================

SB> Is there any formal process to check that there were no edit issues
SB> in the code - which is I assume an extract from the reference 
implementation
SB> That is true here, but will apply again when it goes though the
SB> edit process.

- Stewart