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

Donald Eastlake <> Sun, 11 February 2018 13:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78F15126C22; Sun, 11 Feb 2018 05:57:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dD_gPzKUFY7W; Sun, 11 Feb 2018 05:57:02 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E0D71200C1; Sun, 11 Feb 2018 05:57:02 -0800 (PST)
Received: by with SMTP id l10so11832643oth.1; Sun, 11 Feb 2018 05:57:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9dtQTEzDeiq/aGtofAmPMWTaFm56oCmkxiPWEvkSLOw=; b=L84IPTrQoN22jicnW+GlB7BQ+Y6EP0hW7MK5pGYnSqZEJgc9xM9FHflC2u0gfvCxHP 0mwM+z/X7aH0OykuTuKxPUYQgpZVuSwKR59UhAMVYJS4ip4wxL1N+Pac0vqfQjeorjD6 utv5JHBGzVb55D/Q6KnxjPe0ly7xSd9C973S5teFda0pExHIM7QX3496wHcd562vLdYc PKAMrh6weXarVVgzcYJoWBxztfHDggmlYUhzpsIlpb2hBXbKj+gOdEoXNPiy2vgWVKIO X2UwPU5MoInuyX6BmSpZLSwOgy0UE1hvTQ+qua3Tu9ssS/zB7MycqxnnzYtjZsIGGBiJ IcVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9dtQTEzDeiq/aGtofAmPMWTaFm56oCmkxiPWEvkSLOw=; b=RlfD1V2QIOGWyA1Pt/PlzE9kdNLHpSNXTNjULqMvqc1jYZscvWUfbII7WGB3jYMJgr Wcp7D9grEUVGZdIfza6lz6+iK7YHPPsLVu/D1HFA8mYbNOzMOPUgqx3FM0oTEGHVC96W IBG0RSE23A0ckQdc+6X+1wsYAvCpZp+M7caQ971BYgaLk9Qy9QT6EYM/SNU8uZfpdKpg EIQrOFOdJV8e1S1toa0q+4j+9330cRGh6IJjZdETnQvR7lI/UUBQKizumhZZxZKwl2ke sazM74ROIwtpSWtEdto2IEKGur0p3CF8AhhTeLXV9SIx5pi9HNz6UjDi1TEzymGMCfxx 3VYw==
X-Gm-Message-State: APf1xPAKNI3lOhOLwLsSbpYCzgqrM2Tuo4s2jyCdMDi/RP/du3Gd6uqD lZ7mjUX+43JsgNCUTwOmMKLA2TE1V1u8IDku5jnI4w==
X-Google-Smtp-Source: AH8x226ksgnLfL4Q0oPL9NUrdwFbgTZZNulGXUZAU1tZLzdSHzlqg+GV6nz8PY56GtYvQ7IpWJHfCg25D2kQ8RBj0Bs=
X-Received: by with SMTP id v40mr7002338otf.287.1518357421530; Sun, 11 Feb 2018 05:57:01 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 11 Feb 2018 05:56:46 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Donald Eastlake <>
Date: Sun, 11 Feb 2018 08:56:46 -0500
Message-ID: <>
To: Sarah Banks <>
Cc:,, IETF Discussion <>,
Content-Type: multipart/alternative; boundary="94eb2c191444c0a57c0564f022b0"
Archived-At: <>
Subject: Re: [trill] Opsdir last call review of draft-ietf-trill-ecn-support-05
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 11 Feb 2018 13:57:04 -0000

Hi Sarah,

My apologies for my intemperate language below and anything you found

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

On Mon, Feb 5, 2018 at 11:27 PM, Donald Eastlake <> wrote:

> Hi,
> On Mon, Feb 5, 2018 at 1:22 PM, Sarah Banks <> 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
> > Thanks
> > Sarah