Hi,
On Mon, Feb 5, 2018 at 1:22 PM, Sarah Banks <sbanks@xxxxxxxxxxxxx> wrote:
> Reviewer: Sarah Banks
> Review result: Has Nits
>
> I have reviewed this document as part of the Operational directorate's ongoing
> effort to review all IETF documents being processed by the IESG. These
> comments were written with the intent of improving the operational aspects of
> the IETF drafts. Comments that are not addressed in last call may be included
> in AD reviews during the IESG review. Document editors and WG chairs should
> treat these comments just like any other last call comments.
>
> Status: Ready with Nits
>
> Overall, I think this is a well written document, that could flow better with
> minor revisions.
Perhaps.
> The Abstract and the Introduction include the exact same
> information;
The Introduction is much more detailed.
> I think the document would benefit from having more information in
> the Introduction section, something that expands upon the current text, or
> discusses the use case, and why I care.
I do not agree that the current introduction section needs any
expansion on the topics it already covers. I do not agree that a "use
case" is needed to justify specifying how to add a well know
congestion control building block, already deployed in other contexts,
to a general routing protocol. Not knowing anything about your
background, I have no idea why you should care.
> From time to time I find myself
> wanting to red line the text, for missing words (like "the") - a style
> preference perhaps, but flowing english sentences make a document read easier.
As far as I know the English sentences flow fine. Both I and my
co-author are native English speakers. However, as with any document
of significant length, there are probably some cases that read about
as well with or without an article or the like. And it is certainly
possible there are a tiny number of cases where the flow is rough. If
you had bothered to send a list of the changes you want, I would
probable have made all or almost all of them -- in cases where it is
about as good either way, I usually find it easier not to argue with a
reviewer. But I decline to run in circles trying to guess what you
don't like.
> A lack of discussion on ECT (1) and ECT (0) (Table 1) made this reader stop and
> google; a bit of conversation here would have been helpful.
I am not sure why you went to Google rather look at the ECN RFC 3168
referenced right there in the draft. In any case, the question is how
deep an explanation of the intricacies of ECN marking needs to appear
in a specification of how to support ECN in a particular protocol. I
don't think discussion of ECT(0) and ECT(1) is needed in this
document. However, it would probably be useful to make the referenced
to [RFC3168] more specific by pointing specifically at Section 20
("The Motivation for the ECT Codepoints") of [RFC3168].
> Last, NITS is
> mostly clean, but not entirely. I applaud the call out to ongoing work, and
> Appendix A, but a minor tweak to the doc from Nits output before you send this
> into the queue would be helpful.
The automated Nits checker reports zero errors, its most serious
problem indication, zero flaws, the next most serious, and zero
warnings, its least serious problem indication. True, it does report
one "comment", however, this comment from the Nits checker is
erroneous. Nits checker comments are called comments because they can
often be wrong. There is no real code in the draft that might need to
be extracted and compiled, just one instance of psuedo-code. I think
adding the nits suggested markers for extractable real code to the
psudo-code in this document would just be confusing.
Thanks,
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@xxxxxxxxx
> Thanks
> Sarah