Re: [Gen-art] [aqm] Gen-ART LC review: draft-ietf-aqm-fq-implementation-02
Pete Resnick <presnick@qti.qualcomm.com> Thu, 22 October 2015 17:48 UTC
Return-Path: <presnick@qti.qualcomm.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 A54521B3AB7; Thu, 22 Oct 2015 10:48:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level:
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ue6izAFXGEQY; Thu, 22 Oct 2015 10:48:31 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBF31B3A9E; Thu, 22 Oct 2015 10:48:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1445536110; x=1477072110; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=4BZQfLgS7Wjk6zNvgtwKSQOUwmQFwsPgF1Of+/fZ7l0=; b=F/DNAY86Amjw0yiZHzTAK3NIF1/D7AlA3GwhkDHqMnxhMLP022OmBWFq U0/IqCEwckBPX/VsrX5z1koJ/VKWnAmBB1mwGDcFPsbb6HKCZI65c9g5L Tsokr8QRn3QbTPCLpwLwewCqI0ctYyeAcQVwZFEVspMjkTOwWISvnMbJ7 E=;
X-IronPort-AV: E=McAfee;i="5700,7163,7962"; a="100287916"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Oct 2015 10:48:30 -0700
X-IronPort-AV: E=Sophos;i="5.20,183,1444719600"; d="scan'208";a="1021840814"
Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Oct 2015 10:48:30 -0700
Received: from [10.64.196.175] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 22 Oct 2015 10:48:17 -0700
From: Pete Resnick <presnick@qti.qualcomm.com>
To: Fred Baker <fred@cisco.com>
Date: Thu, 22 Oct 2015 12:48:26 -0500
Message-ID: <B276F038-6C47-43FD-950E-B5CAEBBED738@qti.qualcomm.com>
In-Reply-To: <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> <CC036953-A7F0-45FE-8A5E-4CD58BC7426B@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_65C4E8CA-19A4-425F-A411-29EFAC470018_="
X-Mailer: MailMate (1.9.2r5141)
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To NASANEXM01F.na.qualcomm.com (10.85.0.32)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/ZmTSwE1md7zeooF2cTdWb2EVbAs>
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>, AQM IETF list <aqm@ietf.org>, The IESG <iesg@ietf.org>, Alia Atlas <akatlas@gmail.com>
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 17:48:33 -0000
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 >> <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/> Qualcomm Technologies, Inc. - +1 (858)651-4478
- [Gen-art] Gen-ART LC review: draft-ietf-aqm-fq-im… Pete Resnick
- Re: [Gen-art] Gen-ART LC review: draft-ietf-aqm-f… Jari Arkko
- Re: [Gen-art] Gen-ART LC review: draft-ietf-aqm-f… Fred Baker (fred)
- Re: [Gen-art] Gen-ART LC review: draft-ietf-aqm-f… Pete Resnick
- Re: [Gen-art] [aqm] Gen-ART LC review: draft-ietf… Fred Baker (fred)
- Re: [Gen-art] [aqm] Gen-ART LC review: draft-ietf… Pete Resnick
- Re: [Gen-art] [aqm] Gen-ART LC review: draft-ietf… Fred Baker (fred)
- Re: [Gen-art] [aqm] Gen-ART LC review: draft-ietf… Alia Atlas