[ntpwg] Issues with the NTP draft -06

[Danny Mayer]

I finally managed to get through the draft and I have the following
feedback which I will divide into two parts: substantive and nits.
Overall I find the document to be in pretty good shape though I have
mostly ignored the Appendix A code skeleton.

Substantive:
1) P9 Section 3.2 Second Paragraph
There is no description or indication of what the maximum value of TTL
is or should be or how to decide on what it should be. Similarly there
is no indication of what the minimum number of associations is or how to
decide what it should be.

2) P22: Poll:
Should we allow polling of less than 1 second? We surely don't want to
encourage this.

3) P23:
   Above stratum 1 (secondary servers and clients) this is the reference
   identifier of the server and is intended to detect timing loops.  If
   using the IPv4 address family, the identifier is the four-octet IPv4
   address.  If using the IPv6 address family, it is the first four
   octets of the MD5 hash of the IPv6 address.  Note that, when using
   the IPv6 address family on an NTPv4 server with a NTPv3 client, the
   Reference Identifier field appears to be a random value and a timing
   loop might not be detected.

The problem here is that the refid is to be used to detect timing loops
but it can be any value that can do the job and should be unique for
each server and not interface address. Thus a server should have one and
only one refid irrespective of whether it is using IPv4 or IPv6
addresses. Tying it to an IP address is not really a good idea. Tying it
to a MAC address might be a better idea.

4) P24. Section 7.4 last sentence:
   Other than
   displaying the kiss code, KoD packets have no protocol significance
   and are discarded after inspection.

I'd like to see recipients of KISS codes take actions dependent on the
receipt of some of the codes. Practical experience has shown that the
operators of public servers need to be able to assert more control over
the clients that contact their servers. I'd like to therefore change
this sentence to read as follows:

   Recipients of kiss codes MUST inspect them and in the following cases
   take these actions:
   a) For kiss codes: DENY, RSTR the client MUST demobilize any
      associations to that server and stop sending packets to that
      server;
   b) For kiss code: RATE the client MUST immediately reduce its polling
      interval to that server and continue to reduce it each time it
      receives a RATE kiss code.
   c) Other than the above conditions, KoD packets have no protocol
      significance and are discarded after inspection.

5) P26: Extension Field Format
Shouldn't the Extension Field format be left to the implementation of
the extension field protocol with the exception of the first part which
consists of the field type and the length of the extension field and
it's overall alignment? I'm not clear why association ID, timestamp,
filestamp, etc. would be defined in this document.


Nits:
1) P.5:
   The on-wire protocol described
   in Section 8 is based on a returnable-time design which depends only
   on measured clock offsets, but does not require reliable message
   delivery.
Please add the following:
   Reliable message delivery such as TCP can actually make the delivered
   NTP packet less reliable since retries would increase the delay value
   and other errors.

2) P5:
   All servers and clients who are fully NTPv4 compliance MUST implement
Change to:
   All servers and clients who are fully NTPv4 compliant MUST implement

3) P6:
   of a symmetric active packet with matching no association.  That
Change to:
   of a symmetric active packet with no matching association.  That

4) p7:
   and sends the reply packet as described in Figure 2 of Section 9.2.
Change to:
   and sends the reply packet as described in Figure 2.

5) p9:
Remove the last sentence in the last paragraph in section 3.2
   The reference implementation includes
   intricate means to do this, but these are beyond the scope of this
   document.

This is not relevant here and is implementation dependent.

6) p9-10:
   Under definitions should noise be defined? It is used in the
   reference implementation but not in the document. Dave did send out
   a definition in a recent email message.

7) P22 Figure 12:
   should be change the last entry and make it look like this:
   16     unsynchronized
   17-255 reserved

8) P24: Add the following before Key Identifier in section 7.3:
   Extension Field n: See Section 7.5 for a description of the format of
   this field.

9) P26 and P56 Section 15: IANA allocations of addresses 224.0.1.1 and
:101 needs references to documents.

10) P32 top of page:
   The common names and formula names are interchangeable; formula names
   are intended for equations where space is important.

I have no idea what the reference to "space" means here. Can anyone explain?

11) P37: Figure 24
   4 access denied | The access controls have black
Change to:
   4 access denied | The access controls have blacklisted the source
                     address.

12) P56: Section 15
    Following the policies outlined in [11], new consensus.
Change to:
    Following the policies outlined in [11], new values are to be
    defined by IETF Consensus.

Danny