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

"Fred Baker (fred)" <fred@cisco.com> Thu, 22 October 2015 16:45 UTC

Return-Path: <fred@cisco.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13C81AD370; Thu, 22 Oct 2015 09:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.8
X-Spam-Level:
X-Spam-Status: No, score=-106.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMGqqrun2ACk; Thu, 22 Oct 2015 09:45:40 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5C11AD372; Thu, 22 Oct 2015 09:45:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=338548; q=dns/txt; s=iport; t=1445532339; x=1446741939; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8WXEad6HBbXK+nMvOs5Gn/QW2SmM7DloCYel8a++STs=; b=a8ZmcnQoRaNs9QIuGL1tT4KMXSdhqwlHt2vAWH0rBCXAFVaFDBo9b9u8 UqhjZiFlrNboqtC2iG8jGa/p97C42/sPjsIbVOMDQ1Zy6j0vU3s0/kOO1 cy++E1WkOqe2l3D0iT+7lRWLPajfnZ4+1w/3B261VVuxeTbao0UH7DxD2 s=;
X-Files: Diff: draft-ietf-aqm-fq-implementation-02.txt - draft-ietf-aqm-fq-implementation-04.txt.pdf, draft-ietf-aqm-fq-implementation-04.txt, signature.asc : 208070, 36799, 833
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CfBADpESlW/4UNJK3ODgICAQI
X-IronPort-AV: E=Sophos;i="5.20,183,1444694400"; d="asc'?txt'?scan'208,217";a="200880591"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Oct 2015 16:45:38 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t9MGjcwG023122 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2015 16:45:38 GMT
Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 11:45:17 -0500
Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Thu, 22 Oct 2015 11:45:17 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: Pete Resnick <presnick@qti.qualcomm.com>, Alia Atlas <akatlas@gmail.com>
Thread-Topic: [aqm] Gen-ART LC review: draft-ietf-aqm-fq-implementation-02
Thread-Index: AQHRDOkI/kpnTOeXQUyIF7ey9d4FvQ==
Date: Thu, 22 Oct 2015 16:45:17 +0000
Message-ID: <CC036953-A7F0-45FE-8A5E-4CD58BC7426B@cisco.com>
References: <3A8E6F3E-5C22-42A5-BE98-02CB178D5687@qti.qualcomm.com> <BF21207B-9172-4346-8FF3-773C66A45E05@cisco.com> <1AAC6F51-20F1-49A7-A196-C6A78F2225B2@qti.qualcomm.com>
In-Reply-To: <1AAC6F51-20F1-49A7-A196-C6A78F2225B2@qti.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.183.51]
Content-Type: multipart/signed; boundary="Apple-Mail=_E2415559-0D85-4DA7-B154-652FA260C041"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/5eoAi4yaZAOGsu2MgjN5qYOv5b0>
Cc: "draft-ietf-aqm-fq-implementation.all@ietf.org" <draft-ietf-aqm-fq-implementation.all@ietf.org>, General Area Review Team <gen-art@ietf.org>, The IESG <iesg@ietf.org>, AQM IETF list <aqm@ietf.org>
Subject: Re: [Gen-art] [aqm] Gen-ART LC review: draft-ietf-aqm-fq-implementation-02
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2015 16:45:44 -0000

See attached. Sorry for the oversight.

> On Oct 22, 2015, at 12:09 PM, Pete Resnick <presnick@qti.qualcomm.com> 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 presnick@qti.qualcomm.com <mailto:presnick@qti.qualcomm.com> 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/ <http://www.qualcomm.com/%7Epresnick/>
> Qualcomm Technologies, Inc. - +1 (858)651-4478
> 
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm