Telechat Review of draft-ietf-ntp-extension-field-06

Request Review of draft-ietf-ntp-extension-field
Requested rev. no specific revision (document currently at 07)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-02-02
Requested 2016-01-14
Authors Tal Mizrahi, Danny Mayer
Draft last updated 2016-02-22
Completed reviews Genart Telechat review of -06 by Suresh Krishnan (diff)
Secdir Last Call review of -04 by Sean Turner (diff)
Secdir Telechat review of -06 by Sean Turner (diff)
Opsdir Last Call review of -04 by Tim Chown (diff)
Assignment Reviewer Suresh Krishnan 
State Completed
Review review-ietf-ntp-extension-field-06-genart-telechat-krishnan-2016-02-22
Reviewed rev. 06 (document currently at 07)
Review result Almost Ready
Review completed: 2016-02-22


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

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

   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

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

* Section

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

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