Re: [Last-Call] [Gen-art] Genart last call review of draft-ietf-tsvwg-aqm-dualq-coupled-24

Bob Briscoe <ietf@bobbriscoe.net> Wed, 24 August 2022 16:56 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047A4C14F72D; Wed, 24 Aug 2022 09:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf--HkOqrAS2; Wed, 24 Aug 2022 09:56:55 -0700 (PDT)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4782DC14F692; Wed, 24 Aug 2022 09:56:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:References:Cc:To:From:Subject:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=c6lZoznbNmU2v41EMmp+xZ+myHBssoKds1+VY60zUJQ=; b=zOxBfBdwCN0ZGkrJSHLOBIFehg C6+E0PAAwZAlJQjOwqLJ3tmDINq+xX1U/2KqonzRcpWxzY3ooWbB+wT2OYqHERFa1LBo5yi4AZWz7 OFaMGrlFxO0rZUs4XS3kVBUJazxiX7eabFWuo6K9rO1WQyLiXakktjBV91kQiuQjdcZHlWaTsTlye lTAfMOmYLT7JEoZX4yv1uge5wZUvLQh0Yn7DoZsLXScIjcdpgsUXXD7bDMUJv5/53YXr4yfbLkVBV nPFql1bizcymNbiB84fNTwkowYo6HpbGi1LG8RHxtfN13luYhRaXPB9MCdonAGEy4K+CliKLpr8Rk cPKs1gKQ==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:40020 helo=[192.168.1.4]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from <ietf@bobbriscoe.net>) id 1oQtgS-0007am-GH; Wed, 24 Aug 2022 17:56:50 +0100
Message-ID: <c80736ff-1667-9513-1096-43b182b91f2f@bobbriscoe.net>
Date: Wed, 24 Aug 2022 17:56:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-GB
From: Bob Briscoe <ietf@bobbriscoe.net>
To: Christer Holmberg <christer.holmberg@ericsson.com>, gen-art@ietf.org
Cc: draft-ietf-tsvwg-aqm-dualq-coupled.all@ietf.org, last-call@ietf.org, tsvwg@ietf.org
References: <166124349208.15316.7679975672698377129@ietfa.amsl.com> <7b064d3b-eb6d-331c-b6fc-51e85d649346@bobbriscoe.net>
In-Reply-To: <7b064d3b-eb6d-331c-b6fc-51e85d649346@bobbriscoe.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/oqWYs0JkO0Xua6dubEH-R58hw08>
Subject: Re: [Last-Call] [Gen-art] Genart last call review of draft-ietf-tsvwg-aqm-dualq-coupled-24
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Aug 2022 16:56:59 -0000

Christer,

Yesterday (see [BB] still below) I outlined how I was going to address 
each of your points and promised specific text today.
I've done this via a diff uploaded temporarily to my own website here:

https://bobbriscoe.net/tmp/draft-ietf-tsvwg-aqm-dualq-coupled-25d-DIFF-24.html

Please let me know if I've correctly understood and dealt with all your 
concerns.

Cheers


Bob

On 24/08/2022 00:02, Bob Briscoe wrote:
> Christer,
>
> Somehow I didn't receive your email at all, so I've had to reconstruct 
> it from the web mail archive - I hope my reply preserves the 
> Message-ID and all the distro emails correctly.
> Pls see [BB] inline.
>
> On 23/08/2022 09:31, Christer Holmberg via Datatracker wrote:
>> Reviewer: Christer Holmberg
>> Review result: Almost Ready
>>
>> 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
>>
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-tsvwg-aqm-dualq-coupled-24
>>
>> Reviewer: Christer Holmberg
>> Review Date: 2022-08-23
>> IETF LC End Date: 2022-07-21
>> IESG Telechat date: 2022-08-25
>>
>> Summary:
>>
>> The content and technology of the document is outside the area of 
>> expertise, so
>> my comments are mainly related to the readability of the document. I 
>> list
>> everything as Nits/editorial issues, eventhough some could also be 
>> considered
>> Minor issues.
>
> [BB] Thank you for your comments. They are all useful, finding things 
> we should have found.
>
>>
>> Major issues:
>>
>> N/A
>>
>> Minor issues:
>>
>> N/A
>>
>> Nits/editorial comments:
>>
>> ABSTRACT:
>>
>> I think the Abstract is too long. Also, it starts with the "This 
>> specification
>> defines..." sentence. I think it should start with a few sentences on 
>> what the
>> problem is, and then indicate what the document defines in order to 
>> solve that
>> problem.
>
> [BB] OK, we (the co-authors) have discussed ways to make it shorter.
> I'll suggest specific text in a further email, hopefully tomorrow, But 
> first I wanted to see if you reacted to anything we're proposing in 
> general terms.
> I expect we'll move everything after "The coupling acts like..." to 
> the intro, but we have to read the result back carefully because, at 
> this late stage, major changes like this can break things.
>
> Having cut down the abstract, we'll probably add a sentence sthg like 
> "The framework is not specific about which AQMs to use, but it gives 
> normative requirements for specific implementations, as well as 
> pseudocode example implementations in appendices."
>
>
> I agree that it's good to start from the problem. and the document 
> itself does just that after the 1-para intro. But, in the case of this 
> abstract, the sequence of logic from the original three problems (low 
> delay, low loss, scalable throughput) to this DualQ part of the 
> solution, goes through convoluted intermediate stages each raising a 
> new problem, and eventually ends up with the specific problem that the 
> DualQ solves (which is why the problem section is quite long).
>
> Rather than try to cram all that into the abstract, we decided to 
> start from the last step (the DualQ - that solved the chain of 
> problems), then describe the last problem in the sequence (that it 
> solved), and what the result was (low latency etc.), without trying to 
> explain all the other problems in the sequence. I think the first part 
> of the abstract does quite a good job of summarizing all that, so I 
> wouldn't want to disturb it at this late stage (also bearing in mind 
> that there have been many eyes on this already).
>
>>
>> INTRODUCTION (Section 1):
>>
>> In the beginning of the Section there is a "This document specifies a
>> framework..." statement. Then, there is a similar statement at the 
>> end of
>> Section 1.1., which is only supposed to describe the problem 
>> statement - not
>> the solution. There is also a Scope section (1.2) and a Features 
>> section (1.4),
>> but it is quite difficult to separate between Scope and Features.
>
> [BB]
> 1) You're right that the last para of the problem statement strays 
> into solution mode.
> We'll cut duplication and move any non-dup text elsewhere. I'll give 
> specifics in a further email tomorrow.
>
> 2) AFAICT, "§1.4 Features" solely contains material about what the 
> design achieves (hence the section title),
> whereas "§1.2 Scope" doesn't describe any specific features. It does 
> talk about "benefits", but only in general, where it talks about 
> deployment applicability and so forth.
>
> Can you point to any specific example that triggered your concern 
> about Scope and Features being indistinguishable?
>
> 3) I think Scope would  be better titled as 'Context, Scope and 
> Applicability.'
> Agree?
>
>
>
>>
>> SECTION 2:
>>
>> It seems like the actual requirements for the framework are not 
>> presented until
>> Section 2.5. I think the requirements should come earlier, before the 
>> solution.
>
> [BB] The document describes a general framework for Coupled Dual-Queue 
> AQMs, then the Requirements are the normative statements of what 
> specific implementations of that general framework MUST or SHOULD 
> comply with.
>
> I can see that this ought to be explained and hasn't been. Probably in 
> the abstract, and intro, as well as at the head of the section itself.
> I'll suggest specific text in a further email tomorrow.
>
>
>>
>> SECURITY CONSIDERATIONS (Section 4):
>>
>> There is quite a bit of text in the Security Considerations. In 
>> general that is
>> not a bad thing :)
>>
>> My question is whether the content is actually about security? Much 
>> seem to be
>> more "operational" issues.
>
> [BB] Most of the points are about traffic security (overload, 
> flooding, unresponsiveness, starvation). This is a branch of security. 
> I suspect you're expecting information security, but that's not the 
> only branch of security.
>
> If there's anything in there that you still think is unrelated to 
> security, pls point to it. But I'm pretty sure there isn't.
>
> Regards
>
>
> Bob
>
>>
>>
>>
>>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/