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.
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
