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

[Pete Resnick <[e-mail]>]

You missed the Zhang reference in 2.2.5. Otherwise fine.

pr

On 22 Oct 2015, at 11:45, Fred Baker (fred) wrote:

> See attached. Sorry for the oversight.
>
>> On Oct 22, 2015, at 12:09 PM, Pete Resnick 
>> <[e-mail]> wrote:
>>
>> All of the changes you made look fine.
>>
>> You changed the reference to Brisoce, but didn't change McKenny, 
>> Shreedar, or Zhang. I still think you should.
>>
>> You missed the nit in section 4, paragraph 2 (s/a mark/mark).
>>
>> There's still no explanation of why this is likely to be a useful 
>> document in the future (which may be more for the shepherd writeup 
>> than for the document itself, and given that the IESG is already 
>> doing their work, may be moot).
>>
>> pr
>>
>> On 22 Oct 2015, at 10:47, Fred Baker (fred) wrote:
>>
>> Thanks Pete. I had updated the draft on October 12 in response to 
>> working group comments, so the diff I'm sending is against -02 (which 
>> you reviewed) and includes those changes. I have attached a -04 
>> version, which I plan to post when the repository opens. If you have 
>> other comments or are not satisfied with the changes, it still has 
>> room to change.
>>
>> On Oct 6, 2015, at 6:06 PM, Pete Resnick [e-mail] 
>> <mailto:[e-mail]> wrote:
>>
>> 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 
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> 
>> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq 
>> <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]