Telechat Review of draft-ietf-ntp-extension-field-06
review-ietf-ntp-extension-field-06-genart-telechat-krishnan-2016-02-22-00

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-ntp-extension-field-06.txt
Reviewer: Suresh Krishnan
Review Date: 2016-02-02
Telechat Date: 2016-02-04

Summary: This draft is almost ready for publication as a Proposed Standard
but has some issues that need to be addressed.

* Major

* Section 3

I could not find the text in RFC5905 Section 7.5 that this draft says it is
replacing. Specifically the following "OLD:" text does not exist in RFC5905

"
   In NTPv4, one or more extension fields can be inserted after the
   header and before the MAC, if a MAC is present. If a MAC is not
   present, one or more extension fields can be inserted after the
   header, according to the following rules:

   o  If the packet includes a single extension field, the length of the
      extension field MUST be at least 7 words, i.e., at least 28
      octets.

   o  If the packet includes more than one extension field, the length
      of the last extension field MUST be at least 28 octets. The length
      of the other extension fields in this case MUST be at least 16
      octets each.
"

After a bit of digging, I did find the verified Erratum #3627 that mentions
the text in RFC5905 being incorrect, but I am not sure the acceptance of the
Erratum implies that the "OLD" text in the RFC has been replaced.

* Minor

* Section 7.5.1.1

Not sure how the extension fields specify the use of MAC and the
corresponding algorithm. A reference would be good to have.

* Section 7.5.1.2

Why isn't there a corresponding sender rule for the different MAC algorithm
case that prevents the packet from ever being sent out and consuming bandwidth.

* Section 7.5.1.3

This sentence is hard to parse. Can you split/reword?

"  A MAC MUST NOT be longer than 24 octets if there is no extension
   field present unless through a previous exchange of packets with an
   extension field which defines the size and algorithm of the MAC
   transmitted in the packet and is agreed upon by both client and
   server."

Thanks
Suresh