[Gen-art] Gen-ART LC Review of draft-ietf-ippm-rate-problem-08

[Ben Campbell <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-ippm-rate-problem-08
Reviewer: Ben Campbell
Review Date: 2014-12-22
IETF LC End Date: 2014-12-22
IESG Telechat date: (if known)

Summary: The draft is almost ready for publication as an informational RFC. I have a few comments that might should be considered first.

Major issues:

None

Minor issues:

-- section 3, paragraph 3: "Service testing MUST respect"

Who or what does the MUST apply to? The protocol (or protocol designers)? The users of the protocol? (I note that much of the draft uses the form "The protocol MUST...", is the same meant here?)

-- section 3, paragraph 4:

This paragraph seems to be saying that the protocol must meet other, non-enumerated "practical matter" requirements. It seems like those should be actually enumerated.

-- section 4, paragraph immediately after alpha list:

The first sentence seems to be redundant with normative text right before the list. 

-- section 5, first paragraph:

The first sentence seems to be redundant with normative text in the previous section. If the idea is to point out that the requirements in the previous section, please consider using descriptive language instead of 2119 language. (Repeated normative text tends to be error prone, and creates confusion about which text is authoritative.)

-- section 5, note concerning "vanishing number of symmetrical-rate..."

Does this mean the protocol doesn't have to worry about it, or that while the number is shrinking it still needs to be considered?

Nits/editorial comments:

-- Abstract: second sentence

This sentence is pretty heavy on the sales pitch, and will likely become irrelevant once the work this draft contemplates is done. Please consider whether you really want it in the abstract.  (For the record, I have no objection to the similar language in the intro.)

-- General:

Consider numbering you diagrams and using cross references, rather than "below". Don't count on them being in the same relative position with the text that references them in all possible renderings.

-- Section 1, diagram:

It's not clear to me whether the "User, Device, or Host" label(s)" are intended to be one label for all 3 access methods, or if user is tied to fiber, Device to copper, etc. I assume the former, but the diagram looks more like the latter.

-- 2, paragraph starting with "Support of active measurement methods will be addressed here..."

What is meant by "here"? This document? Or the working group?  (If the former, consider present tense.)

-- 2, last paragraph:

This draft _is_ the problem statement, right? Consider saying "problem statement mandates" rather than "will mandate".

-- section 3, paragraph 6: "it is expected...MUST"

The phrase "it is expected" seems odd in combination with MUST. Does this mean it _might_ be a MUST? Assuming that's not the case, I suggest dropping "it is expected that". 

-- section 4, preface to alpha list:

This means "All _supported_ categories", correct?

-- section 4, 2nd to last paragraph:

What actionable guidance is intended by this paragraph?

-- section 4, last paragraph "(these could be listed later, if desired)"

Listed in this document, or somewhere else. Is this text that was intended to be deleted?

-- same paragraph: "... protocol entity that collects results."

Is this the RECEIVER? The REPORTER? I suggest sticking to the defined terms.