Hi,

I have reviewed this document as part of the Operational directorate's 
ongoing effort to review all IETF documents being processed by the IESG.  These 
comments were written with the intent of improving the operational aspects of the 
IETF drafts. Comments that are not addressed in last call may be included in AD 
reviews during the IESG review.  Document editors and WG chairs should treat 
these comments just like any other last call comments. 

The draft clarifies certain points around how NTPv4 optional extension headers, as
originally defined in Section 7.5 of RFC 5905.  In particular this draft considers the 
relationship between extension fields and Message Authentication Codes (MACs),
and how a host should handle unrecognised extension fields.

Overall I think the document is Ready, but I have a couple of questions below that
the AD may wish to consider, or the authors may want to clarify. Note I am by no 
means an expert on the specifics of the operation of NTP; these points may not
be applicable or may already have been discussed by the WG.

Of the two topics the draft covers, the updated text on the relationship of extension 
fields and MACs seems fine.

My first question is on extension fields with unknown Field Types. Section 3 states 
that a host SHOULD ignore a packet with an extension field of an unknown Field 
Type, and MAY drop the packet altogether if policy requires it.

Firstly, are there any lessons learnt from the lengthy debate leading to RFC 7045 on
handling IPv6 Extension Headers that might be applicable here? While IPv6 Extension 
Headers may be more critical to specific protocols using them, RFC 7045 encourages 
forwarding of unknown headers by intermediate nodes rather than filtering, which is a
more ‘aggressive’ position than this draft adopts.

Related, this draft talks about host behaviour, or behaviour by hosts receiving packets
with unknown Field Types. It may be worth explicitly referring to forwarding nodes and
end hosts in the way RFC 7045 does?

My second question is regarding the Security Considerations section in this draft, 
where the reader is referred back to RFC 5905. Does the rise in NTP abuse in DDoS 
attacks since 2010, when RFC 5905 was authored, warrant any further consideration 
here? Is it possible that a client can find servers which will under certain circumstances
generate a long extension field list, potentially increasing any DoS amplification factor?
If that is the case, should that be limited? If it’s not the case, should it be explicitly
stated that it’s not a concern in the Security Considerations?

Best wishes,
Tim