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/
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
