Hi Sarah, My apologies for my intemperate language below and anything you found offensive.
Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] On Mon, Feb 5, 2018 at 11:27 PM, Donald Eastlake <[email protected]> wrote: > Hi, > > On Mon, Feb 5, 2018 at 1:22 PM, Sarah Banks <[email protected]> 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 > [email protected] > > > Thanks > > Sarah >
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
