Last Call Review of draft-ietf-ippm-2679-bis-03
review-ietf-ippm-2679-bis-03-secdir-lc-kumari-2015-08-13-00
Request | Review of | draft-ietf-ippm-2679-bis |
---|---|---|
Requested revision | No specific revision (document currently at 05) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2015-08-11 | |
Requested | 2015-07-30 | |
Authors | Guy Almes , Sunil Kalidindi , Matthew J. Zekauskas , Al Morton | |
I-D last updated | 2015-08-13 | |
Completed reviews |
Genart Last Call review of -03
by Brian E. Carpenter
(diff)
Secdir Last Call review of -03 by Warren "Ace" Kumari (diff) Opsdir Telechat review of -05 by Al Morton |
|
Assignment | Reviewer | Warren "Ace" Kumari |
State | Completed | |
Request | Last Call review on draft-ietf-ippm-2679-bis by Security Area Directorate Assigned | |
Reviewed revision | 03 (document currently at 05) | |
Result | Has nits | |
Completed | 2015-08-13 |
review-ietf-ippm-2679-bis-03-secdir-lc-kumari-2015-08-13-00
Be ye not afraid -- I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Version reviewed: draft-ietf-ippm-2679-bis-03 Summary: Ready with nits. IMO Sec ADs do not need to pay attention. This document is well written and clear. I found only a small number of nits... Security Considerations is well written and complete. Section 1: Note: This section's placement currently preserves minimal differencer between this memo and RFC 2679. The RFC Editor should O: differencer P: differences R: typo Section 3.5: + A given methodology will have to include a way to determine whether a delay value is infinite or whether it is merely very large (and the packet is yet to arrive at Dst). As noted by Mahdavi and Paxson [RFC2678], simple upper bounds (such as the 255 seconds theoretical upper bound on the lifetimes of IP packets [RFC0791]) could be used, O: could be used, P: could be used; R: grammar/otherwise it's a run-on sentence Section 3.6: + At the Src host, select Src and Dst IP addresses, and form a test packet of Type-P with these addresses. Any 'padding' portion of the packet needed only to make the test packet a given size should be filled with randomized bits to avoid a situation in which the measured delay is lower than it would otherwise be due to compression O: otherwise be due to compression P: otherwise be, due to compression R: readability Section 3.7.2: To the extent that the difference between wire time and host time is accurately known, this knowledge can be used to correct for host time measurements and the corrected value more accurately estimates the O: measurements and the corrected value more accurately estimates the P: measurements, and the corrected value more accurately estimates the R: Grammar/run-on sentence -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf