Subject: [trill] Opsdir last call review of draft-ietf-trill-ecn-support-05

From: Sarah Banks <[email-masked]>
Date: Mon, 05 Feb 2018 10:22:01 -0800

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. The Abstract and the Introduction include the exact same
information; 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.  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.
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. 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.

Thanks
Sarah

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 5 Feb 2018 23:27:52 -0500

Hi,

On Mon, Feb 5, 2018 at 1:22 PM, Sarah Banks <[email-masked]> wrote:
> 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
> 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

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.

> 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

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
 [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 11 Feb 2018 08:56:46 -0500

Hi Sarah,

My apologies for my intemperate language below and anything you found
offensive.

Donald