Subject: [RTG-DIR] RtgDir review: draft-ietf-ippm-rt-loss-03.txt

From: Dan Frost <[email-masked]>
Date: Wed, 21 Mar 2012 15:57:42 +0000

Hello,

I have been selected as the Routing Directorate reviewer for this
draft. The Routing Directorate seeks to review all routing or
routing-related drafts as they pass through IETF last call and IESG
review. The purpose of the review is to provide assistance to the Routing
ADs. For more information about the Routing Directorate, please see
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-ippm-rt-loss-03.txt
Reviewer: Dan Frost
Review Date: 21 March 2012
IETF LC End Date: 19 March 2012
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be
resolved before publication.

Comments:
This document supplies a definition for round-trip packet loss in terms of
the IP Performance Metrics framework.  It is straightforward and clearly
written.

General observation: It's not clear to me what the IPPM WG strategy is for
security considerations sections in metric definition documents.  For
example, the security section of this document more or less repeats the
one in (for example) RFC 2681, which itself duplicates verbatim the one in
RFC 2680, and the issues discussed are general ones with measurement
protocols rather than specific ones with the metric that is the subject of
the document.  There's probably a better way to organize this.

Major Issues:
No major issues found.

Minor Issues:
1. Although it's probably obvious to most readers, it would be helpful to
provide a brief informal definition of "round-trip loss" early in the
introduction.  A mention of the venerable "ping" procedure would also not
be amiss.

2. Most of the text seems to assume an "active" or test-based measurement
approach, but Section 9.2 refers to passive measurement.  It would be
helpful to discuss the applicability of the latter approach.

3. Section 9.3 mentions the use of cryptographic hashing "to discourage
the kind of interference mentioned above"; while this would mitigate the
second form of interference, it wouldn't help with the first.

Nits:
1. The phrase "as immediately as possible" that appears a couple of times
in the text (and that seems to originate in RFC 5357) is a bit
unfortunate.  "Immediately" or "as quickly as possible" are better.

2. Section 5.4, second paragraph: s/affects/effects/

3. Section 8, second paragraph: s/Two key features ... is described/Two
key features ... are described/

4. Section 9.3, first paragraph:
OLD
   it is possible to change the processing of the packets (e.g. increasing
   or decreasing delay) that may distort the measured performance.
NEW
   it is possible to change the processing of the packets (e.g. increasing
   or decreasing delay) in a way that may distort the measured performance.
END

Cheers,
-d