Re: [trill] Opsdir last call review of draft-ietf-trill-ecn-support-05
Donald Eastlake <d3e3e3@gmail.com> Sun, 11 February 2018 13:57 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 78F15126C22; Sun, 11 Feb 2018 05:57:04 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 dD_gPzKUFY7W; Sun, 11 Feb 2018 05:57:02 -0800 (PST)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 4E0D71200C1; Sun, 11 Feb 2018 05:57:02 -0800 (PST)
Received: by mail-ot0-x232.google.com with SMTP id l10so11832643oth.1; Sun, 11 Feb 2018 05:57:02 -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=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; d=1e100.net; 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 10.157.17.171 with SMTP id v40mr7002338otf.287.1518357421530; Sun, 11 Feb 2018 05:57:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.67.205 with HTTP; Sun, 11 Feb 2018 05:56:46 -0800 (PST)
In-Reply-To: <CAF4+nEH_dTnHOX3UJgLn2NuKBvKS7ibyXp2L-iEH1=PEfMJj=g@mail.gmail.com>
References: <151785492150.5822.7062354913097657938@ietfa.amsl.com> <CAF4+nEH_dTnHOX3UJgLn2NuKBvKS7ibyXp2L-iEH1=PEfMJj=g@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sun, 11 Feb 2018 08:56:46 -0500
Message-ID: <CAF4+nEG7EZuetZXrsRFyFAF4NMZqSuZaRrBThGcAGxiWg=5_Nw@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: multipart/alternative; boundary="94eb2c191444c0a57c0564f022b0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/iPeHHn8AidYJyZIdRmUmTSTq-AY>
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: Sun, 11 Feb 2018 13:57:04 -0000
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 d3e3e3@gmail.com On Mon, Feb 5, 2018 at 11:27 PM, Donald Eastlake <d3e3e3@gmail.com> wrote: > 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 >
- [trill] Opsdir last call review of draft-ietf-tri… Sarah Banks
- Re: [trill] Opsdir last call review of draft-ietf… Donald Eastlake
- Re: [trill] Opsdir last call review of draft-ietf… Donald Eastlake