This document has been reviewed as part of the ART area review team's ongoing
effort to review key IETF documents. When done at the time of IETF Last Call,
the authors should consider this review as part of the last-call comments they
receive.

I've looked at the reviews from Genart, Opsart, and Tsvart so I won't repeat
any of the issues they raised.

I think I understand the part of the design that gets cryptographically verified
replies from time servers, and denounces servers that return results implausibly

far from others. But I don't understand how clients "without any idea of what
time it is" set the time. I'm guessing that if they get a set of sufficiently
close replies, it uses some average of them, but the discussion on section 6
only talks about a client that already has a time, not one that doesn't.

As an editorial point, this document has a lot of MUST and SHOULD language.
While it's not wrong, I find documents easier to read if the MUSTs are used to
highlight things that a reader might get wrong. For example, 5.2.2 says that the
NONC tag MUST contain the nonce, but it's hard to imagine a reader expecting
otherwise so "the NONC tag contains the nonce" would do. 

On the other hand, I understand SHOULD to mean MUST unless you have a good
reason to do something else, so some hints would be helpful to tell us what the
exceptions are in the 30 places where the draft says SHOULD. 

For example, in 5.1 "A request ... SHOULD include the tag SRV. Other tags SHOULD
be ignored by the server. ... The size of the request message SHOULD be at least
1024 bytes when the UDP transport mode is used. To attain this size the ZZZZ tag
SHOULD be added to the message." 

Why would you omit SRV? Why wouldn't the server ignore other tags? When would a
shorter message be OK? Why wouldn't you use the ZZZZ tag? Some of these might
have explanations, others might better be MUST or not use 2116 words.