[Gen-art] Gen-ART LC review: draft-ietf-aqm-fq-implementation-02

[Pete Resnick <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair.  Please treat these comments just like any 
other last call comments.

For more information, please see the FAQ at

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

Document: draft-ietf-aqm-fq-implementation-02
Reviewer: Pete Resnick
Review Date: 2015-10-6
IETF LC End Date: 2015-10-15
IESG Telechat date: 2015-10-22

Summary:

This document is in fine shape and is generally ready for publication 
(caveat some minor things below); no major issues at all. One overall 
question though:

Neither the document nor the shepherd writeup explain why this document 
will be useful for future work. It may very well be (I'm no expert in 
the area), but it's at least not obvious to me that it is. You've 
already pulled the lever to start an IETF-wide Last Call, but before it 
goes to the IESG for them to work on, perhaps it would be good to say 
why the WG thinks this is useful as a permanent publication in the RFC 
series as against just a working reference document for the WG. Is some 
future WG likely to want to refer to this document when doing queue 
management work?

Presuming it is desirable to publish, here are the remainder of my 
comments. Some of them are right on the line between "minor issue" and 
"editorial" (they're editorial, but did cause some confusion for me), so 
I just grouped them all together here.

Minor issues and nits/editorial comments:

In 2.1.3, calling out any author by name is a bit weird in an IETF 
document, but in this case the reference is to RFC 7141, an IETF BCP. 
While I know Bob's a smart guy and I'm sure he contributed substantially 
to that document, I don't think calling out a just one author of an IETF 
consensus document is appropriate. (I think it's stylistically a little 
weird to use author names in general in IETF documents, but at least in 
two of the other cases, it's a single author of a non-IETF document; 
calling out Shreedhar and not Varghese is still weird to me, though I 
understand it is common practice in academic literature. If it were me, 
I'd reference the title, not the author. That said, you're going to have 
to fight it out with the RFC Editor regarding whether those URLs are 
"stable references".)

In 2.2, second sentence: The *algorithm* isn't empty or not empty, the 
*queue* is empty or not empty. This had me really confused for a bit. 
Please fix the sentence.

In 2.2.1ff: Instead of "a method, called 'enqueue'", say "an enqueue 
method". Personally, I'd prefer "function" or "operation" instead of 
"method" throughout, but that's your choice really. (Using "a method, 
called 'enqueue'" implies an actual implementation in a particular kind 
of programming language.) Whichever terminology you choose, pick one and 
stick to it throughout the document. Right now you switch. (Obviously 
the same comment for "a method, called 'dequeue'".)

In 2.2.2 and 2.2.3, each in the 3rd paragraph, the verb "removes" does 
not have a subject. I think you need to say "the dequeue function" 
somewhere in each sentence.

In 2.2.2, your reference to using a hash as a classifier threw me. I 
figured out what you meant, but it was an unfamiliar concept to me. But 
I'm also not sure why it's useful to call out a particular kind of 
classifier in the first place. I'd think it would be better to just 
describe generally how a classifier can be used to put data into 
different queues. (And shouldn't this be part of the enqueue paragraph? 
Are classifiers used to dequeue?)

In 2.2.4, last paragraph: WRR is not defined. Did you mean DRR?

In 4, paragraph 2, s/a mark/mark

I hope that's helpful.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]