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

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

(sorry, there was a typo for the int-ads alias, resnding with fixing the error).

On Fri, Jun 15, 2018 at 1:12 PM  <[e-mail]> wrote:
>
> 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