[ntpwg] Re: SNTP

["David L. Mills" <[e-mail]>]

Alfred,

The I-D has now survived all the editors controlling its progress over a 
year and a half and three revisions. The primary reason for speed here 
is timely advice to implementors in response to recent meltdowns at 
NIST, USNO and U Wisconsin. I can't change it now, as that might result 
in review restart and further delay. The conversion to Postel ASCII was 
not done by me and what you see online is only a draft copy. I assume 
the editors will find and fix whatever needs.

The OSI reference is once and forever political. I survived GOSIP and 
the messy politicized outcome of the National Academy report. I am well 
aware that nobody can buy it and so advised the Air Force, for which I 
was a consultant. Eventually, the COTS issue is what doused the fires 
and the services were told to buy anything as long as it was COTS and 
not a MILSPEC. Apparently, the wonks didn't notice that IP and TCP are 
MILSPECs.

It was never my intention to use the term "anycast"; that was a typo 
corrected in the final draft. What I meant to say was "manycast", which 
is intended to support multiple simultaneous servers using mitigation 
algorithms. Even so, the IP multicast model is imperfect and some of the 
the RFC references may be obsolete. I do hope the editors have caught 
and revised accordingly.

I can't get very excited over the MD5 issues. In prinicple, any digest 
in the OpenSSL library can be dropped in, but then is the issue of 
backwards compatibility, selecting one from a number of digests, etc. 
It's confusing enough to support multiple signature/digest schemes for 
certificates, etc., which is what the NTPv4 autokey does now. In that 
scheme the digest key is changed on every use.

I will in fact keep your comments in mind for a possible new edition and 
also for the NTPv4 specification now in progress. Thanks very much for 
taking extra care in your constructive and useful comments. I am copying 
this to the NTP spec community for possible further discussion.

Dave

Alfred � wrote:

>Hello,
>
>I once had intended to send you some comments on RFC 2030,
>but until now I never found the time to do so, in fact.
>
>Now, last week, I stumbled over the your SNTP I-D,
>"draft-mills-sntp-v4-00", and used the weekend to closely
>study the text, taking into account my earlier notes on
>RFC 2030 (never sent) and comparing it with the previous SNTP
>RFCs in general.
>
>BTW: I also discovered the recent effort by a new WG to update
>     the (aged) NTP specifications, which is very welcome.
>     If my time allows I will study the WG drafts this
>     summer - if they get published until then :-)
>     But for now, I want to just consider the SNTP draft.
>
>Although there are some general considerations mentioned first,
>in my subsequent notes I'll mostly follow the text of the draft
>step by step - although this may lead to some minor repetitions.
>
>
>Notation:
>========
>
>I have intentionally changed the line formatting of some text
>fragments to remain within usual email line width restrictions,
>and occasionally use change bars ("|") in column 1 to emphasize
>lines with proposed textual changes (beyond line re-breaking),
>or to tag parts of text by 'underlining' with "^" characters.
>
>To precisely locate positions in the text of the draft,
>I will use the following notation, with syntactic tokens
>in <angle brackets> explained immediately below:
>
>    {s.<sect>/<dir><para>}
>    {s.<sect>/<dir><para>.<dir><line>}
>                      ... two kinds of section relative addressing,
>or:
>    {p.<page>/<dir><para>.<dir><line>}
>    {p.<page>/.<dir><line>}
>    {p.<page>/<dir><para>}
>                      ... three kinds of page relative addressing,
>
>where:
>  <sect>   is a section number,
>  <page>   is a page number,
>  <para>   is the paragraph number (whithin a section or page)
>           [ A 'logical' paragraph of a section might span two (or
>           even more) pages, and the resulting paragraph "fragments"
>           are counted as 'physical' paragraphs within those pages
>           for the purpose of page relative addressing. ]
>  <line>   is the line number within a page or paragraph;
>           sometimes line ranges <line1>-<line2> will be used.
>  <dir>    is the [optional] counting direction, relative to the
>           preceding token (section/page/paragraph, respectively):
>       't' ... from top (default)
>       'b' ... from bottom
>
>(The paragraph spec or the line spec is omitted if full paragraph
>or a line within a page is referred to, respectively.)
>
>E.g.:  {s.2/4.b4}  or  {p.6/1.1}  both locate the first text line
>  on page 6  -- the 4th paragraph of section 2 spans pages 5 & 6 ;
>  {p.10/b3}  locates the 3rd-to-last paragraph on page 10.
>
>
>Comments
>========
>
>(1) -- general note --
>
>  Is it really still worth taking care of OSI protocols ?
>
>  The lack of publicly available specifications and the
>  apparent complexity of these protocols has lead to the
>  "victorious career" of the TCP/IP protocol suite and the
>  widespread non-implementation of most ISO/OSI specs that
>  can be observed today.
>
>(2) -- general note --
>
>  The increasing number of attacks against MD5 should perhaps
>  lead to the consideration of SHA-1 as a replacement for MD5
>  - at least at those places where changes from RFC 2030 are
>  introduced by the draft, and backwards compatibility is not
>  an issue.
>
>  [ There is much rumour now on new attacks announced against
>    SHA-1 as well, but it apparently remains open until the
>    detailed presentation of those results (due for the
>    EUROCRYPT'05 conference next month) how serious these
>    threats are to be taken in reality. ]
>
>  According to the current 'state of the art' in cryptography,
>  it seems generally inadvisable to recommend or use MD5 in
>  new specifications. The NIST meanwhile even has begun to limit
>  the use of SHA-1, i.e. has started the process to eventually
>  phase out SHA-1.
>
>(3) -- general note --
>
>  Unfortunately, the notion of 'anycast' introduced in RFC-2030
>  and used throughout the draft does not conform to the anycast
>  model in the IPv6 Addressing Architecture (now: RFC-3515) and
>  the meanwhile pervasive and widespread use in IPv4
>  - for DNS Root and Top-Level Domain servers (cf. RFC-3258 and
>    <http://www.isc.org/pubs/tn/?tn=isc-tn-2003-1.html>,
>    <http://f.root-servers.net/>, <http://k.root-servers.net/>,
>    <http://www.denic.de/> {for 'de.' name servers}
>  - for web server replication (e.g., by the globally acting content
>    providers, SPEEDERA and AKAMAI);
>
>  The IPv6 and IPv4 Anycast model is based on *unicast addresses*
>  and routing protocol/configuration support, whilst the [S]NTP
>  anycast model is based on *multicast addresses* and some kind of
>  'reverse multicast' fiction. (Indeed, it is ordinary [multi-source]
>  multicast!)
>  (Note: IPv6 A-A officially still restricts anycast very much due
>  to "lack of experience". Apparently, sufficient experience with
>  global anycast now *does* exist in the Internet.)
>
>  It once took me quite a while to concieve this fundamental
>  difference of 'anycast' traffic models in RFC-2030.
>
>  With the widespread use of anycast conforming to the IPv4/IPv6
>  anycast model, it appears to me that it would be very useful
>  to add an additional paragraph to section 1 defining the
>  [S]NTP specific 'anycast' model, emphasizing and explaining
>  the difference to the IPv6/IPv4 routing assisted anycast model.
>
>  This certainly would avoid a lot of confusion, and help to let
>  the NTP specific 'anycast' notion in place in the remainder of
>  the text.
>
>  It might be useful as well to add a reference to RFC-2526 (for
>  IPv6 anycast addresses) somewhere in the text.
>
>(4) {p.1/.b3}
>
>  The appropriate reference for
>        "Internet Protocol version 6 (IPv6)"
>  should be 'RFC-2640' which obsoleted RFC-1883.
>
>(5) {p.4/t2.b3}
>
>  See (2) above: Use of truncated SHA-1 instead of truncated MD5
>  should be considered.
>
>(6) {p.4/t4.t3-5}
>
>  RFC-1240 has been re-classified as HISTORIC by RFC-2556
>  published 6 years ago, in March 1999.
>
>  I am in doubt whether reference to such spec is useful.
>  See also (1) above.
>
>  If the RFC-Ed (or the IESG) consider this reference a
>  Normative Reference (which seems appropriate according to
>  current published policy), this would inhibit any progress
>  within - or even entering of - the Standards Track for the
>  RFC-to-be !
>
>(7) {p.4/t4.b4}
>
>  RFC-2030 (and its predecessors) notoriously used the notion
>  of message 'header' for the *body* of the [S]NTP messages.
>
>  Since there is nothing to follow, it would be better to
>  replace  "With the header formats defined in this memo ..."
>  by:  "With the message formats defined in this memo ..."
>
>  At many other places in the draft, a similar change of notion
>  (from RFC-2030) already has been applied.
>
>(8) {p.4/b2}
>
>  Now that (since RFC-2030) the indented paragraph {p.4/t3}
>  has been inserted, it might be better to move the 'meta-note'
>
>    "In the following, indented paragraphs such as this one contain
>     information not required by the formal protocol specification,
>     but considered good practice in protocol implementations."
>
>  to an earlier place in the text, e.g. just below {p.3/t3} .
>
>(9) {s.2/1.t2-3}
>
>  There's a simple word omission in the 1st sentence of section 2.
>  Replace:
>
>    "Unless excepted in context, reference to broadcast address means
>     IPv4 broadcast address, IPv4 multicast group address or IPv6
>     site-local scope address."
>
>  by:
>
>    "Unless excepted in context, reference to broadcast address means
>     IPv4 broadcast address, IPv4 multicast group address or IPv6
>     site-local scope multicast address."
>                     ^^^^^^^^^^
>
>(10) {s.2/1.t7}
>
>  "anycast (multipoint to point) addressing"  ... see (3) above!
>
>(11) {s.2/4}, in particular {p.5/.b1} ans {p.6/.t1}
>
>  SNTP uses "Any-Source Multicast (ASM)".  IGMPv3 (RFC-3376) has been
>  specified to introduce "Single-Souce Multicast (SSM)", and the
>  current Standards Track position of IGMPv3 has not obsoleted
>  IGMPv1 and IGMPv2.
>  Therefore, it might still suffice (and even be better - to avoid
>  reference conflicts and to enhance the chances of SNTPv4 in the
>  Standards Track 'race') to make reference (for the case of IPv4)
>  to IGMPv1 (RFC-1112 == STD 5, part 6) and / or IGMPv2 (RFC-2236).
>
>  Additionally, for the case of IPv6, reference should be granted
>  to the 'Multicast Listener Detection' (MLD) protocol, i. e.
>  MLDv1 (RFC-2710) and / or MLDv2 (RFC-3810).
>
>(12) {s.3/2} = {p.6/b1}
>
>  To enhance the precision of the specification, in the second
>  sentence of this paragraph, it should be expressed that the
>  timestamp 'origin' is given in UTC.
>  In the third sentence, a verb apparently has disappeared in the bit
>  bucket.
>  The last sentence has not been updated when the 'randomizing'
>  recommendation has been introduced (later on in the text).
>
>  Therefore, I recommend to enhance the full paragraph now saying:
>
>   "Since NTP timestamps are cherished data and, in fact, represent the
>    main product of the protocol, a special timestamp format has been
>    established.  NTP timestamps are represented as a 64-bit unsigned
>    fixed-point number, in seconds relative to 0h on 1 January 1900.  The
>    integer part is in the first 32 bits and the fraction part in the
>    last 32 bits.  In the fraction part, the non-significant low order
>    bits are not specified and ordinarily set to 0."
>
>  to:
>
>   "Since NTP timestamps are cherished data and, in fact, represent the
>    main product of the protocol, a special timestamp format has been
>    established.  NTP timestamps are represented as a 64-bit unsigned
>    fixed-point number, in seconds relative to 0h on 1 January 1900, UTC.
>    The integer part is in the first 32 bits and the fraction part is in
>    the last 32 bits.  In the fraction part, the non-significant low
>    order bits are not specified and ordinarily set to 0 or randomized."
>
>(13) {p.7/t1.b2}
>
>  MD5 --> SHA-1 ??    ... see (2) above!
>
>(14) {p.7/t2.t2}
>
>  The 1st sentence in this paragraph seems to be truncated a bit.
>  I propose to change:
>
>   "The NTP format allows convenient multiple-precision arithmetic and
>    conversion to UDP/TIME message (seconds), but does complicate the
>    conversion to ICMP Timestamp message (milliseconds) and Unix time
>    values (seconds and microseconds or seconds and nanoseconds)."
>
>  to read:
>
>   "The NTP format allows convenient multiple-precision arithmetic and
>|   conversion to UDP/TIME message format (seconds), but does complicate
>    the conversion to ICMP Timestamp message (milliseconds) and Unix
>    time values (seconds and microseconds or seconds and nanoseconds)."
>
>(15) {p.7/t3}
>
>  According to the strong recommendation for randomizing of the
>  non-significant fraction bits, I propose to change the figure:
>
>   "                      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
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                           Seconds                             |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                  Seconds Fraction (0-padded)                  |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+"
>
>  to better read:
>
>   "                      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
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                           Seconds                             |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |              Seconds Fraction (0-/random-padded)              |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+"
>
>(16) {p.7/b1.t2}
>
>  As time passes by ... the text ages - as we do.  And thus, the
>  number of years left until the '2^32-seconds-catastrophe' declines
>  as well. So please update the phrase:
>
>   "As the NTP timestamp format has been in use for over 20 years, it
>    remains a possibility that it will be in use 33 years from now
>    when the seconds field overflows."
>
>  to become:
>
>   "As the NTP timestamp format has been in use for over 20 years, it
>|   remains a possibility that it will be in use 31 years from now
>    when the seconds field overflows."
>
>(17) {p.7/b1.b3-1}
>
>  The statement in RFC-2030 on 2000 was erroneous. This already has
>  been corrected in the draft (Thanks!), but the fact is stated in a
>  temporal form no more appropriate today: as seen from today, the
>  year 2000 indeed *was* a leap year.
>  For some people, it might also be worth to additionally state that
>  1900 was *no* leap year.
>  Thus, I propose enhancing the final sentence on p. 7 :
>
>    "          ...  Note that when calculating the correspondence,
>     2000 is a leap year and leap seconds are not included in the
>     reckoning."
>
>  to better read:
>
>    "          ...  Note that when calculating the correspondence,
>|    2000 was a leap year and 1900 was no leap year, and leap seconds
>     are not included in the reckoning."
>
>(18) {p.8/t1.t3}
>
>  In accordance with the goal to extend the coverage of SNTP beyond
>  IPv4, I propose to amend the first sentence on page 8 with explicit
>  mention of IPv6, from:
>
>   "Both NTP and SNTP are clients of the User Datagram Protocol (UDP)
>    specified in RFC-768 [POS80], which itself is a client of the
>    Internet Protocol (IP) specified in RFC-791) [DAR81]."
>
>  to:
>
>   "Both NTP and SNTP are clients of the User Datagram Protocol (UDP)
>    specified in RFC-768 [POS80], which itself is a client of the
>    Internet Protocol, Version 4 (IPv4) specified in RFC-791) [DAR81]
>    or the Internet Protocol, Version 6 (IPv6) -- see section 8 of
>    RFC-2460 [..<tbd>..]."
>
>  (or similar).
>
>  Because there's now some hype regarding UDP-Lite (RFC-3828), you also
>  might consider immediately adding a note defending against this, e.g.:
>
>   " ... Transport of (NTP and) SNTP over UDP-Lite (RFC-3828) is not
>    considered appropriate and therefore NOT supported by this
>    specification."
>
>(19) {p.8/t2.b1}
>
>  The reference tag for RFC-3022 should be "[SRI01]" (instead of
>  "[SRI02]") -- that RFC indeed has been published in January 2001.
>
>(20) {p.9/.b2}
>
>  In the table specifying the encoding and semantics of the LI field,
>  there's a typo originating from RFC-1361 that has survived through
>  RFC-1769 and RFC-2030.
>
>  Please correct the line:
>
>   "     2        last minute has 59 seconds)"
>                                            ^
>  to become:
>
>   "     2        last minute has 59 seconds"
>
>  In the draft, it might also improve readability if this table were
>  moved to just below the explanatory text for LI, on page 8 (there's
>  enough space). Such re-arrangement might automatically optically
>  improve the page break positions within the remaider of section 5,
>  but perhaps it is not worth the effort because the page layout
>  certainly will change when the draft is mangled into an RFC ...
>
>(21) {p.10/t5.b1}
>
>  The final sentence in the description of the `Mode` field says:
>
>    "The other modes are not used by SNTP servers and clients."
>
>  This is not strictly true, as can be seen, e.g. on page 16.
>  It migth be better to state:
>
>    "Some of the other modes can optionally be supported partially
>     by SNTP servers and clients to gain enhanced interoperability
>     with NTP clients and servers, respectively; see section 5 and
>     section 6 for details."
>
>  (or similar).
>
>(22) {p.10/t6}
>
>  The explanation of the `Stratum` field omits directives for client
>  messages. I propose to re-state the paragraph:
>
>   "Stratum: This is a eight-bit unsigned integer indicating the stratum.
>    This field is significant only in SNTP server messages, where the
>    values are defined as follows:"
>
>  to better say:
>
>   "Stratum: This is a eight-bit unsigned integer indicating the stratum.
>|   This field should be set to zero in client messages; it is significant
>    only in SNTP server messages, where the values are defined as follows:"
>
>  Similar textual enhancements migth be appropriate for other field's
>  descriptions as well.
>
>(23) {p.10/b1}
>
>  The explanation of the `Poll Interval` field seems to be misleading
>  and /or incomplete.
>
>  Unfortunately, the term 'poll interval' is not defined fully until
>  (the first paragraph of) section 10.
>
>  The text on page 10 says:
>
>                     "... the resulting value is the maximum interval
>     between successive  messages ..."               ^^^^^^^
>                       ^^
>
>  Shouldn't this value *limit* the polling, i.e. allow the server to
>  specify the *minimal* interval between [periodic] *client* messages
>  it will support/allow ?
>
>  (Admittedly, it might be difficult to give a short and precise
>  decription of the semantics of this field in the [restricted]
>  SNTP environment that does not conflict with the full semantics
>  in the NTP environmnet.)
>
>  Additionally, it might be appropriate to enhance the wording of
>  the subsequent phrase,
>                          "..., where the values range ..."
>  to:
>                          "..., where usual values range ..."
>  or:
>                          "..., where useful values range ..."
>
>(24) {p.11/t1.t4}
>
>  The last consideration above ("the" -> "usual" or "useful")
>  also applies here.
>
>(25) {p.11/t4}
>
>  Considering the expected time span until the eventual publication
>  of the draft as an RFC, the launch of the Galileo satellite system
>  (as a commercial, high precision successor to the GPS satellite
>  system) will not be too far ahead for consideration.
>  It therefore might make sense to already establish a standard
>  `Code` value (abbreviation) for the Galileo system and append
>  a corresponding line to the table in Figure 2.
>
>  BTW: -  Why "Figure" , not "Table" ?
>       -  The figure on p. 7 -- see (15) above -- has no such
>          "Figure" caption; it might have deserved one !
>
>(26) {p.12/t5}
>
>  I propose to enhance the explanation of the `Originate Timestamp`:
>
>   "Originate Timestamp: This is the time at which the request departed
>    the client for the server, in 64-bit timestamp format."
>
>  to say:
>
>   "Originate Timestamp: In reply messages, this is the time at which
>    the request departed the client for the server, in 64-bit timestamp
>    format."
>
>(27) {p.12/t6}
>
>  The explanation of the `Receive Timestamp` has been changed since
>  RFC-2030, to say:
>
>   "Receive Timestamp: This is the time at which the request arrived at
>    the server or the reply arrived at the client, in 64-bit timestamp
>    format."  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>  IMHO, this change is inappropriate and in contradiction to subsequent
>  text; e.g., the table on page 14 defines (among others):
>
>   "Timestamp Name          ID   When Generated
>    ------------------------------------------------------------
>    Receive Timestamp       T2   time request received by server
>    Destination Timestamp   T4   time reply received by client"
>
>  The latter definitions are in conformance with the use of terms
>  throughout the remainder of the text.
>  Therefore, I suggest to remove again the words tagged '^^^^' above.
>
>(28) {p.12/t8}
>
>  The final paragraph of section 4 is titled:
>
>    "Authenticator (optional): ..."
>
>  Now, since RFC-2030 the original optional `Authenticator` field in
>  "Figure 1" has been replaced by two optional fields, `Key Identifier`
>  and `Message Digest` -- without any change in the wording intended
>  to referencing these fields.
>
>  The most simple textual change to accomodate the situation might be
>  to change above wording to:
>
>    "Optional authentication fields: ..."
>
>(29) {p.12/b1.t1}
>
>  I suggest to change the 1st sentence of section 5 from:
>
>    "A SNTP client can operate in unicast, broadcast or anycast modes."
>                                                                    ^
>  to:
>
>    "A SNTP client can operate in unicast, broadcast or anycast mode."
>
>(30) {p.13/t3.t1}
>
>  According to (7) above, I propose to change the phrase:
>
>   "A unicast or anycast client initializes the NTP message header, ..."
>                                                            ^^^^^^
>  to read:
>
>   "A unicast or anycast client initializes the NTP message fields, ..."
>
>(31) {p.13/t3.b1}
>
>  The text says:
>
>                                   " ...  For this purpose, all of the
>    NTP header fields shown above are set to 0, except the Mode, VN and
>    optional Transmit Timestamp fields."
>    ^^^^^^^^
>
>  This might lead to the mis-interpretation this field to be optional
>  in SNTP messages. In fact, the field is mandatory, but it is optional
>  to insert a non-zero value. The following (or similar) wording might
>  be used to express this fact more precisely:
>
>                                   " ...  For this purpose, all of the
>    NTP header fields shown above are set to 0, except the Mode and VN
>    field, and - optionally - the Transmit Timestamp field."
>
>(32) {p.13/t4.b2}
>
>  There's another typo that already has survived 3 RFCs :
>  RFC-959 in fact is STD 9 -- on FTP !!
>
>  The text should refer to "... Version 0 (RFC-958) ..."
>                                                 ^
>
>(33) {p.13/t5.t2}
>
>  Another loss of verb. Please replace:
>
>   "While not necessary in a conforming client implementation, in unicast
>    and anycast modes it  highly recommended that ..."
>                        ^^
>  by:
>
>   "While not necessary in a conforming client implementation, in unicast
>    and anycast modes it is highly recommended that ..."
>
>(34) {p.14/.t1}
>
>  The new typographic style of references to field names is broken
>  in the first line on page 14.
>  In conformance with the remainder of the text, I propose to change:
>
>           "... The server copies this field to the originate timestamp
>    in the reply and sets the Receive Timestamp and ..."
>
>  to instead read:
>
>           "... The server copies this field to the Originate Timestamp
>    field in the reply and sets the Receive Timestamp and ..."
>
>(35) {p.15/.t7}
>
>  In the table on page 15 summarizing the SNTP client operation, the
>  `Mode` line seems to be inadvertently copied from the similar table
>  in section 6 resulting in entries that do not conform with the body
>  of the text.
>
>  Summarizing from the text, I find:
>    SNTP clients should always set the Mode field to 3 in the request
>    and expect to receive a Mode field value of 4 in the reply - may
>    it be obtained from a full NTP server or a strict SNTP server in
>    conformance with section 6. The Mode field values 1 / 2 should
>    only appear in the context of a SNTP *server* interoperating with
>    a NTP client.
>
>  Therefore, the line:
>
>   "     Mode                     1 or 3      2 or 4         5 "
>
>  should be changed (back) to read:
>
>   "     Mode                     3           4              5 "
>
>(36) {p.15/.t18}
>
>  The final line in the same table,
>
>   "     Authenticator            optional    optional       optional"
>
>  should - according to item (28) above - preferrably be changed to:
>
>   "     authentication fields    optional    optional       optional"
>
>(37) {s.6/t2.t4-5}
>
>  The following phrase contains an implementation detail that
>  is not very useful for the purpose of protocol specification
>  and might even be considered confusing in this place:
>
>                                             "... A unicast or anycast
>    server receives a request (NTP mode 3), modifies certain fields in
>    the NTP header, and sends a reply (NTP mode 4), possibly using the
>    same message buffer as the request."          ^^^^^^^^^^^^^^^^^^^^
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>  I propose to just omit the tagged words.
>
>(38) {p.16/b1.t3-6}
>
>  I propose to clarify the wording by emphasizing the distinction
>  between NTP and SNTP clients (interworking with a SNTP server) -
>  cf. item (21) above by amending the sentence:
>
>                              "... This allows clients configured in
>    either client (NTP mode 3) or symmetric active (NTP mode 1) to
>    interoperate successfully, even if configured in possibly suboptimal
>    ways."
>
>  to read:
>
>                              "... This allows NTP clients configured
>    in either client (NTP mode 3) or symmetric active (NTP mode 1) to
>    interoperate successfully with a SNTP server, even if configured in
>    possibly suboptimal ways."
>
>(39) {p.16/b1.b1} / {p.17/t1.t1}
>
>  There's an issue for the interoperation of SNTP servers in broadcast
>  mode with [S]NTP clients not supporting SNTPv4 :
>
>  The text (and indeed, already RFC-2030) requests that SNTP servers
>  set the VN field to 4 in broadcast messages. This prohibits SNTP
>  broadcast client operation for clients only supporting, e.g., v3.
>
>  Are there severe reasons for this fixed VN value selection ?
>
>  One might, at least, consider server broadcast operation with
>  (statically) configurable broadcast VN, or servers implementing
>  alternating broadcast of v3 and v4 tagged Mode 5 messages.
>
>(40) {p.17/t1.t2}
>
>  The text apparently is truncated; I propose to replace:
>
>                                          "... and the Poll field set to
>    the nearest integer base-2 logarithm of the poll interval."
>
>  by:
>                                          "... and the Poll field set to
>    the nearest integer to the base-2 logarithm of the poll interval."
>
>(41) {p.17/t3.b3-2}
>
>  The final sentence of that paragraph states:
>
>                      "Once synchronized to a reference source, the LI
>    field is set to one of the other three values and remains at the last
>    value set even if the reference source becomes unreachable or turns
>    faulty."
>
>  This is certainly an inappropriate rule. It would indefinitely
>  inhibit leap second announcements -- or even worse, permanently
>  lead to leap second announcements.
>
>  I therefore recommend to change this sentence to read:
>
>                      "Once synchronized to a reference source, the LI
>    field is set to one of the other three values and remains within
>    this range even if the reference source becomes unreachable or turns
>    faulty."
>
>(42) {p.17/b2.t4}
>
>  Previous RFC text used to talk repeatedly of the "decimal point" in
>  the contect of binary (i.e. base-2) fixed-point fractional numbers.
>  This has been remedied meanwhile in most places of the draft text.
>  It should be corrected here as well; therefore, replace
>
>               "... logarithm of the number of significant bits to the
>    right of the decimal point in the NTP timestamp format. ..."
>                 ^^^^^^^
>  by:
>
>               "... logarithm of the number of significant bits to the
>    right of the fraction point in the NTP timestamp format. ..."
>
>(43) {p.18/.t4}
>
>  There's a simple typo; replace:
>
>   "The Transmit Timestamp field are set to the time of day when the
>    message is sent."            ^^^
>
>  by:
>
>   "The Transmit Timestamp field is set to the time of day when the
>    message is sent."
>
>(44) {p.18/.t6}
>
>   The immediately following sentence,
>
>                      "In broadcast messages the Receive Timestamp field
>     is set to zero and copied from the Transmit Timestamp field in other
>     messages."         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>   contradicts the entry in the 2nd-to-last line of the table below.
>   From (the spirit of) the remainder of the text I conclude the
>   intention that SNTP servers should not make a distinction between
>   the time of receipt of a client request and the transmission of
>   the server reply because these servers are considered to be 'fast'.
>   This interpretation is in conformance with the `Receive Timestamp`
>   and the `Transmit Timestamp` entries in the table at the bottom
>   of page 18.
>   Since the Transmit Timestamp value of the request is to be copied
>   into the *Originate* Timestamp field of the reply, I suspect the
>   above wording to be in error. Perhaps, that sentence should read:
>
>                      "In broadcast messages the Receive Timestamp field
>     is set to zero and set to the current time of day in other messages."
>
>(45) {p.18/t2.t5}
>
>   The 'Broadcast' column of the 'VN' line in the table on p. 18
>   corresponds to the recommendation discussed in item (39) above.
>
>   If any of my suggestions is followed, the columnar entry "4"
>   should be replaced by "(see text)".
>
>(46) {p.18/t2.t11}
>
>   The 'Precision' line in this same table contains mathematical
>   nonsense (inherited from RFC-2030): The number of significant
>   bits already *is* the (base 2) logarithm of the precision;
>   therefore,
>                          "-log2 server signinficant bits"
>   should be replaced by:
>                          "server signinficant bits"
>
>   BTW: Since 195x (I do not know exactly the year), we have
>     international standards on mathematical formula elements
>     uniquely defining the abbreviations:
>         ln := log_e   ,  lg  :=  log_10  , and   lb := log_2
>     We've been tought this notation in school, from the first
>     contact with logarithms.
>     Why do Americans almost always avoid these latter abbreviations?
>
>(47) {s.7/t1.b2-1}
>
>  Since the roll-out of CIDR - RFC-1518 et al., September 1993 -,
>  IPv4 address masks are fundamentally obsolete (because they allow
>  subnet construction inherently incompatible with CIDR) and remain
>  only a reminiscence of the days of fixed class A/B/C IP networks.
>  But since then, implementors obstinately and persistently use
>  address mask constructs instead of the appropriate prefix notation
>  and representation.
>
>  The text - aimed at IPv4 and IPv6 - still recommends address masks
>  or address-mask pairs.
>  In conformance with current routing and MIB definition practice in
>  the IETF, I strongly recommend getting rid of legacy wording and
>  using prefix and/or address range notation instead.
>  The language used should accomodate IPv6 peculiarites as well.
>
>  Therefore, replace the sentence:
>                                             "Ordinarily, SNTP servers
>    and clients are expected to operate with little or no site-specific
>    configuration, other than specifying the client IP address, subnet
>    mask, gateway."
>
> by:
>                                             "Ordinarily, SNTP servers
>    and clients are expected to operate with little or no site-specific
>|   configuration, other than specifying the client interface IP address,
>|   subnet prefix length, and, for IPv4, the default router."
>
>(48) {s.7/t3.t4}
>
>  [Continution of item (47) above]
>
>  I recommend to replace the phrase:
>                                                    "Unicast and anycast
>    servers and broadcast clients may be configured with a list of
>    address-mask pairs for access control, ..."
>
> by:
>                                                    "Unicast and anycast
>    servers and broadcast clients may be configured with a list of
>|   subnet prefixes or address ranges for access control, ..."
>
>(49) {s.7/t3.t6}
>
>  To accomodate the intended applicability to IPv6, I propose to
>  replace the sentence:
>
>                                                  "Multicast servers and
>    clients must implement the IGMP protocol and be provided with the
>    local broadcast or multicast group address as well."
>
>  by:
>
>                                                  "Multicast servers and
>|   clients must implement the IGMP protocol for IPv4 and/or the MLD
>|   protocol for IPv6, and be provided with the local broadcast or
>|   multicast group address to be used for SNTP as well."
>
>(50) {p.22/b1}
>
>  There's a typo; replace
>
>   "7. A client SHOULD re-resolve the server IP address on a periodic
>       intervals, but not less ..."
>
>  by:
>
>   "7. A client SHOULD re-resolve the server IP address on periodic
>       intervals, but not less ..."
>
>  or:
>
>   "7. A client SHOULD re-resolve the server IP address on a periodic
>       interval, but not less ..."
>
>(51) {p.23/t6}
>
>  If OSI support shall continue to be claimed, change:
>
>   "Server IP Address: This is the IPv4, IPv6 or OSI address of the
>    server."
>
>  to read:
>
>   "Server Address: This is the IPv4, IPv6 or OSI address of the server."
>
>  else change it to read:
>
>   "Server IP Address: This is the IPv4 or IPv6 address of the server."
>
>  or, shorter:
>
>   "Server Address: This is the IPv4 or IPv6 address of the server."
>
>  (The text on page 24 is not prepared for OSI addressing support.)
>
>  In the text for step 2..4 on page 24, repeatedly replace "IP address"
>  by "server address" or similar, accordingly.
>
>(52) {p.23/t7.t5}
>
>  A hit of the famous 'word duplex effect'; change:
>
>                                "A DNS request for a generic server name
>    such as ntp.mytimeserver.com results should result in a random
>    selection of server IP addresses available for that purpose."
>
>  to:
>                                "A DNS request for a generic server name
>|   such as ntp.mytimeserver.com should result in a random selection of
>    server IP addresses available for that purpose."
>
>  [and optionally omit the "IP" as well -- see (51).]
>
>(53) {s.12}
>
>  This is a list of hints for the "Informative References" section
>  without giving detailed paragraph/line numbers.
>
>  The ref. [COL94] does not appear in the text. "(RFC-1629)" *does*
>  appear in the 'Abstract'. I conclude: see item (1) above !
>
>  The ref. [DEE96] does not appear in the text. "(RFC-1883)" *does*
>  appear in the 'Abstract'. RFC-1883 is obsoleted by RFC-2640.
>
>  Ref. [DOB91], RFC-1240, is now considered Historic by RFC-2556,
>  see item (6) above.
>
>  The ref. [EAS95] does not appear in the text.
>  Since RFC-2030, where this ref. appeared as well, that has become
>  RFC 2065, since obsoleted by RFC 2535, then "updated" (some people
>  would say, demolished, piece by piece) by many RFCs, and just now
>  almost all this stuff has been obsoleted by RFC-4033..4035 , but
>  some pieces normatively referenced elsewhere now have been left
>  alone in the Normative Nirwana.   :-)  :-)  :-)
>
>  The ref. [HIN96], and "RFC-1884", does not appear in the text.
>  RFC-1884 has been obsoleted by RFC-2373, which in turn has been
>  obsoleted by [HIN03]. ==> Remove this ref.
>
>  The ref. [PAR93], and "RFC-1546", does not appear in the text.
>  It might be interesting as a historical reference with respect
>  to note (3) above.
>
>  It might be useful to add ref's to the superseded predecessors
>  of the memo, RFC-1361, RFC-1769, and RFC 2030.
>
>
>Finally, just to be exhaustive ...
>
>(54) {s.13}
>
>  (The IESG will certainly request more substantive security
>  considerations for publication of the draft as an RFC.)
>
>(55) {s.14}
>
>  (Section 14 does not reflect the extended author list given in
>  the title heading of the draft.)
>
>
>
>Ouggghhhhhhhh -- these comments have grown lengthy now.
>I still hope some parts will be considered useful.
>
>Best regards,
>  Alfred H�nes.
>
>