I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by the
IESG for the IETF Chair. Please treat these comments just like any other
last call comments. For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-ntp-checksum-trailer-04
Reviewer: Paul Kyzivat
Review Date: 2016-02-23
IETF LC End Date: 2016-03-01
IESG Telechat date: 2016-03-03
Summary:
This draft is on the right track but has open issues, described in the
review.
Major: 2
Minor: 3
Nits: 1
(1) Major:
Section 3.3 references [NTP-Ext] (draft-ietf-ntp-extension-field) as
justification for why existing implementations won't have any trouble
with this extension. But some (most?) existing implementations won't
comply with [NTP-Ext], but rather only with RFC5905. This section
doesn't explain how *those* implementations will behave. ISTM there is
some possibility that they won't behave well.
(2) Major:
Section 3.2 says:
This length guarantees that the host that receives the packet
parses it correctly, whether the packet includes a MAC or not.
[NTP-Ext] provides further details about the length of an
extension field in the absence of a MAC.
I am not reviewing [NTP-Ext], but I consulted it in an attempt to
understand. I found this logic, and the references, to be confusing and
seemingly contradictory:
In [NTP-Ext] I find:
... However, a MAC is
not mandatory after an extension field; an NTPv4 packet can include
one or more extension fields without including a MAC (Section 7.5 of
[RFC5905]).
While section 7.5 of [RFC5905] contradicts that:
In NTPv4, one or more extension fields can be inserted after the
header and before the MAC, which is always present when an extension
field is present.
The text that allows extension fields without a MAC is an update to
RFC5905 in section 3 of [NTP-Ext]. But that isn't very clear about how
one is expected to decipher this. I *think* the intended logic is:
If the packet length is more that 24 bytes in excess of the size
of a packet with no extensions or MAC, then it must contain at
least one extension. In that case, process extensions until the
remaining size of the packet is less or equal to 24. Then, if bytes
remain process them as a MAC.
IMO this draft should not progress until this is specified *somewhere*,
probably in [NTP-Ext].
[IMO this technique is a horrible hack. I hope there was no better
backward compatible alternative. But this comment isn't a formal part of
this review.]
(3) Minor:
Section 3.2 says:
The extension field includes 22 octets of padding. This field
SHOULD be set to 0, and SHOULD be ignored by the recipient.
In my experience SHOULD is dangerous when not explained. I would
recommend either changing it to MUST or providing an explanation of
conditions that would justify violating the SHOULD.
(4) Minor:
While section 3.2 carefully defines the format of the Checksum
Complement option, it never specifies how the content of that field is
generated or used. An example of that calculation is shown in appendix
A, but that isn't normative. A normative specification of the content of
the field is needed. IIUC it is to simply be ignored by the recipient.
It would be good to say that too.
(4) Minor:
This document has a normative reference to RFC5905 and an informative
reference to [NTP-Ext]. But [NTP-Ext] has normative updates to RFC5905
and this document has dependencies on those changes, so it needs a
normative reference to that document.
(6) Nit/Question:
In section 3.1, IIUC the timestamp engine will need to know that the
Checksum Complement field is present before it updates the packet. Is it
assumed that engine will assume that to be so, and will not be invoked
unless it is? It might be helpful to say something about this. If not, I
don't see how it can work.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
