|
List Info Thread: ***SPAM*** FW: Comments on NTP draft -06
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
***SPAM*** FW: Comments on NTP draft -06 |
|
List Info Thread: ***SPAM*** FW: Comments on NTP draft -06
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
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
_______________________________________________
ntpwg mailing list
ntpwg