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