[Int-dir] Intdir early review of draft-ietf-ntp-bcp-06

[神明達哉 <[e-mail]>]

I am an assigned INT directorate reviewer for <draft-ietf-ntp-bcp-06>. These
comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these
comments just like they would treat comments from any other IETF
contributors and resolve them along with any other Last Call comments
that have been received. For more details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/ .

Based on my review, the document IS NOT ready to go to IETF Last Call
and therefore CANNOT be forwarded to the IESG.  See the next paragraph
for my rationale.  That said, I don't know the history or past
discussions on this document, so my points may simply be a rehash of
previous discussions in the WG for which the WG reached a different
consensus.  If so, I wouldn't challenge that consensus and my
recommendation can be "it IS ready and CAN be forwarded to the IESG".
As a technical document I found it generally well-written and useful
(although I have to note that I'm not an NTP expert and it's quite
possible that I overlook something very primitive).

I have the following DISCUSS/ABSTAIN level issue:

  This draft heavily relies on the behavior and features of a
  particular implementation developed by ntp.org.  It seemed to me to
  be quite awkward for an IETF document, especially for a BCP RFC.
  Personally, I would generally expect a BCP to provide generic,
  implementation-independent information.  Some
  implementation-specific information such as how to configure ntpd to
  meet particular recommendations would be a nice addition, but I
  would like it to be clearly separated from the main content, either
  as a different section or as an appendix.

The following are other issues I found with this document that SHOULD
be corrected before publication:

- On a related point to the above DISCUSS level issue, it's
  confusing to me that this draft is sometimes ambiguous about whether
  it talks about an implementation-dependent feature or about a
  general protocol/operational topic.  For example, Section 4.2 refers
  to NTP 'mode 6' and 'mode 7'.  It was not clear to me whether these
  modes mean the same as described in RFC 5905.  According to Figure 1
  of the RFC mode 6 means 'broadcast client' and mode 7 isn't defined;
  Figure 10 says mode 6 means 'NTP control message' and mode 7 means
  'reserved'.  So this may be 'mode 6' in this draft refers to Figure
  10 of the RFC while 'mode 7' refers to a implementation-specific
  feature of ntpd.  These may be too obvious for readers already
  familiar with NTP, but it was quite confusing for someone without
  much background of the protocol and implementation, like me.
  Although a technical document could require some level of
  prerequisites, I think this draft could be more reader friendly and
  be clearer about the general and implementation-specific discussions
  (this comment would still apply regardless of how we resolve the
  'DISCUSS-level' issue).

- Section 3.1 seems a bit awkward to me.  It doesn't talk about how
  it's relevant to NTP, while talking about quite a lot of details of
  BCP 38.  It would fit in the entire draft context better if it
  discusses the implication of BCP 38 for NTP (such as UDP-based
  protocols are more susceptible to address spoofing attacks).  I
  would also consider making the section more concise, just referring
  to BCP 38 instead of discussing many details of it.

The following are minor issues (typos, misspelling, minor text
improvements) with the document:

- Section 5.3: s/in in/in/
   this effort was at draft #10, and in in the 'final call' process.

- Section 6.1:

   [...] To minimize
   information leakage, leaf-node hosts should drop all incoming NTP
   packets except mode 4 response packets that come from unknown
   sources.

  On a first read this sentence didn't make sense to me.  I guess the
  intent was:

   To minimize information leakage, leaf-node hosts should drop:
   - all incoming NTP packets that come from unknown sources
   - unless they are mode 4 response packets

  But the original sentence could also read:

   To minimize information leakage, leaf-node hosts should drop:
   - all incoming NTP packets
   - unless they are mode 4 response packets that come from unknown
     sources

  Perhaps this one is clearer and less ambiguous?

   [...] To minimize
   information leakage, leaf-node hosts should drop all incoming NTP
   packets that come from unknown sources except mode 4 response
   packets.

--
JINMEI, Tatuya