I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-ntp-ntpv4-proto-11.txt
Reviewer: Brian Carpenter
Review Date: 2009-03-09
IETF LC End Date: 2009-02-23
IESG Telechat date: 2009-03-12

Summary:  In good shape, some issues noticed
--------

Comments:
---------

I have seen no response to my Last Call review.

This is a large and complex document and I trust the WG to have done 
a good job on the core technical aspects. So my technical comments
are rather limited.

I admire the ASCII-art formulas, e.g. page 38.

Major issues:
-------------

There is a summary in the Introduction of the new features compared to
NTPv3 and SNTPv4. However, I think it would be highly useful for implementors 
to have a detailed list of the technical additions and changes. Maybe this
could be done as a separate document or even just a web page at ntp.org.

In Fig. 9 (leap indicator values) there is an 'alarm condition' value,
but I didn't find a description of what should be done after receiving
this indicator. Maybe this is obvious to one skilled in the art, but
I couldn't figure it out. (If the answer is 'do nothing', I'm not sure
it is really an alarm.)

I note that there some tables of code values (e.g. Figs. 9 - 11, 22)
that are *not* to be IANA-maintained. That implies that any updates would
need to update the present document. Is that OK? 

[ref3] appears to be required reading if somebody wants to implement
Autokey. If so, it needs to be a normative reference. In that case, the 
RFC3967 procedure is needed, and was not followed for the Last Call.
But more fundamentally, why isn't this a reference to
draft-ietf-ntp-autokey-04? (That doesn't completely solve the problem,
since that draft says "Intended status: Informational".)

ID-nits also finds:

** Downref: Normative reference to an Informational RFC: RFC 1345

Is that really a normative reference? Is it really needed? If the answers
are yes, this should also have been identified in the Last Call.

[Side comment: please don't shoot the messenger just because he knows the
rules about normative references.]


Minor issues:
-------------

The address given for one of the editors (Jim Martin) bounces, and he apparently
hasn't posted to the WG list in over a year.

Reference to [RFC2434] instead of [RFC5226]. Also, reference to "IETF consensus",
which RFC5226 changed to "IETF review".

I was quite confused by the informative references coming first. I guess there's
no rule, but most people put normative ones first.

The draft was issued with the old copyright text. Somebody should check whether
it can carry the RFC5378 copyright or whether it also needs the pre-RFC5378
disclaimer. It seems quite likely that the disclaimer will be needed. It's 
especially important to be clear about the usage rights for the sample code 
in Appendix A, even though the code is clearly stated not to be executable as-is. 

ID-nits gives quite a few complaints about funny spacing etc.