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

Donald Eastlake <d3e3e3@gmail.com> Tue, 06 February 2018 04:28 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B1C126CF9; Mon, 5 Feb 2018 20:28:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hzp6QZFkLHGp; Mon, 5 Feb 2018 20:28:08 -0800 (PST)
Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51DB12DA4A; Mon, 5 Feb 2018 20:28:08 -0800 (PST)
Received: by mail-ot0-x234.google.com with SMTP id v5so556596oth.5; Mon, 05 Feb 2018 20:28:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=INEUPxdcaaGiVPo7RCV5hnm+Z2XK323YtjEv9NR30b4=; b=OdoNYa+485T8DLs+uyENwOYQ1varP2auQtuM7Jooe2GdlaRpU6p6z4bPFjziskR2Wl ilB5KqSy6wmBJv2WJI2/K/nbamMRYK/dECyNkoBIUKAvXc/DC24bSuJY3BiXAHl1VfeO p73F/hGQeijIIvaf9imcc5Qanhz6GaDl3uyNRP/E90raOZMOVvtK9m1ueWHbL/RtsxKO WgnCiYcLqLnPTtFCEE3CjzdXl8w7tVHIap64xeNMexRiSO6KHRbOSdcEN48Yt7DkDt8W x4UertfqvF+/BHb7Ij2J0P2jIbIi5UHCaFD44ue2dZfsT9mJiSkZf4lgG/f4wtxxhg+z Jvyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=INEUPxdcaaGiVPo7RCV5hnm+Z2XK323YtjEv9NR30b4=; b=gbWrgULkt/stsjCarZIqT6PG8UDtuXR3KSTmU+xvsDtqKf9IXMYgcGmYl9kFbz1JL6 96L/yAaIM4Ml7DGTOlh+a7kRwPWdid9nBLMvXf+9uxFGDUlxnnBqvMWUixXKvjcWpcrx qzJU8GETH6an6lo0o9syS/cm/rsNyj0MVH2rHLCvHeFbSjuZ9cRKZP4phjI1mYqV1bmy D+DECWREnInHjQNeLPa+Z6P5GPKJWVvh79pas4Qwf2GA3wkrYGI6wrXTdxSiuLIDvH4W AYmQmZjZr8qjsBSF1CsHEFptAICfBiQdn4SmRfutRLtjWIaK8kTnhze8N6Px1UWGfq4P NTlw==
X-Gm-Message-State: APf1xPBg6vFfDocwKfOuj/41pgMes6BGfEaoAudN+Pc7iFM3+LCKQgwx dbJzW2afCLu3PIXcqVlT57TqxbTqbtuCahdntR87oA9m
X-Google-Smtp-Source: AH8x224GT6m7n8sdE6KXIT9nXv206N7tIqy3qZC8Txc1koPircDeXCgMgOGZr302xlnJRgGcogeKVmvVykkN6Nm1AOQ=
X-Received: by 10.157.19.46 with SMTP id f43mr730180ote.139.1517891287817; Mon, 05 Feb 2018 20:28:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.67.205 with HTTP; Mon, 5 Feb 2018 20:27:52 -0800 (PST)
In-Reply-To: <151785492150.5822.7062354913097657938@ietfa.amsl.com>
References: <151785492150.5822.7062354913097657938@ietfa.amsl.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 5 Feb 2018 23:27:52 -0500
Message-ID: <CAF4+nEH_dTnHOX3UJgLn2NuKBvKS7ibyXp2L-iEH1=PEfMJj=g@mail.gmail.com>
To: Sarah Banks <sbanks@encrypted.net>
Cc: ops-dir@ietf.org, draft-ietf-trill-ecn-support.all@ietf.org, IETF Discussion <ietf@ietf.org>, trill@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/__D9x3DzcMU0ZVImGcM0GkaSd9o>
Subject: Re: [trill] Opsdir last call review of draft-ietf-trill-ecn-support-05
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Feb 2018 04:28:11 -0000

Hi,

On Mon, Feb 5, 2018 at 1:22 PM, Sarah Banks <sbanks@encrypted.net> 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@gmail.com

> Thanks
> Sarah