Skip to main content

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