[ntpwg] ***SPAM*** Re: Comments on NTP draft -06
Danny Mayer
mayer at ntp.isc.org
Thu Jun 28 14:11:49 UTC 2007
Stewart Bryant wrote:
> 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?
In this case the V4 version of the NTP protocol.
> Protocol Version 6 address family. NTPv4 includes fundamental
>
> 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?
>
You have a point here especially as Dave Mills is constantly tweaking
the algorithms to improve the results. However I think that the point
trying to be made here is that there is a set of algorithms being used
and not just one that needs to be used to bring the clock into
compliance with UTC. I don't think it's the algorithms themselves that's
set in stone, it the fact that there's a set of them each of which can
be implemented any way the implementor pleases. I cannot craft better
language on this, but I'm sure others can.
> =========
>
>
>
> As a standard practice, timing network topology should be organized
> SB> Should or MUST?
I think "should" is sufficient here as NTP goes to great lengths to
discard anything that does not conform to its idea of valid (for some
meaning of valid). timing loop avoidance and synchronization distance
minimization just helps the calculations.
> 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
I think that Dave Mills really means distance spanning tree from a
mathematical point of view.
> 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.
>
Well this looks like a duplicate of Figure 35 on P54. We should
eliminate one or the other.
> ============
>
>
> 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??
Those candidates which most recently responded with an NTP packet.
> 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?
It is. This is a definition of what the term means rather than how it is
to be estimated.
> 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?
If you mean instances of servers, then this is just an example. The
reference implementation lets you have as many as you want but it will
ignore some if it has too many but even that limit can be changed.
>
> ==========
>
>
> 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?
What's calculated when you boil everything down is the amount that your
system clock differs from the reference clocks. That number may be
positive or negative but NTP never calculates time in the future or
past, just the amount your clock disagrees and the frequency changes
necessary to bring it into line.
>
> ===========
>
>
> 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?
The recipients of NTP packets the server responds with, or in the case
of broadcast the ones it sends out that are received by clients.
> 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?
Yes. This is assigned by IANA. See Section 7.2 (p18) and also Section 15.
> SB> BTW can you run NTP over DCP or perhaps one of the SCTP modes?
In theory you can run it over any protocol, but you would would break
things like autokey which makes use of the IP address of the client and
server to authenticate. It's really designed for UDP/IP.
>
> ==========
>
> +-----------+------------+-----------------------+
> | 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?
32-bit word, to be specific.
> 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?
Not exactly. It's actually the last day of a specific quarter though I
don't think it's ever happened yet on any day but the last day of the year.
> | 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
This looks like an implementation-specific detail.
>
> 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
Yep, that's wrong. The precision can be calculated from this but it
isn't the minimum time.
>
> ===============
> +------+----------------------------------------------------------+
> | 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?
If don't think that there is a need for that. It's just advisory about
what's being used. That could change if this becomes required
information, eg for tracability.
> SB> Does there need to be an IEEE1588 code?
What's that for?
>
> =============
>
> 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?
Meaning what?
> =============
>
> 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?
>
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?
Right now it's informational, with the exception of my recommendation to
make DENY, RSTR, and RATE have the client do something. Is there a need
for this in the 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?
words are 32-bits in this document.
>
> 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?
>
I would expect this to be unsigned. However note the UDP limitations
prevent it getting so big that the sign bit ever becomes an issue.
> ==========
>
>
> 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
No, the problem is that some servers (especially true of embedded
systems) don't have the datetime stored in NVR and have no idea when
they start what time it is. The 32-bit limit on the size of the variable
used in the call on traditional Unix boxes in which they use to retrieve
the time from the system clock is what causes this problem.
>
>
> ============
>
> 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?
No, see above.
>
> ==============
>
>
> 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.
There was a dropped partial sentence that I already noted in my response.
Danny
>
> 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
More information about the ntpwg
mailing list