[bess] Barry Leiba's No Objection on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Thu, 17 December 2020 05:20 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: bess@ietf.org
Delivered-To: bess@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 397183A14F6; Wed, 16 Dec 2020 21:20:11 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bess-mvpn-fast-failover@ietf.org, bess-chairs@ietf.org, bess@ietf.org, Stephane Litkowski <slitkows.ietf@gmail.com>, slitkows.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <160818241069.5464.9229012950551022998@ietfa.amsl.com>
Date: Wed, 16 Dec 2020 21:20:11 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/0DK2z15p_oAmFMXfem3HozvSeFk>
Subject: [bess] Barry Leiba's No Objection on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2020 05:20:18 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-bess-mvpn-fast-failover-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

— Section 1 —

   The procedures described in this document are optional to enable an
   operator to provide protection for multicast services in BGP/MPLS IP
   VPNs.  An operator would enable these mechanisms using a method
   discussed in Section 3 in combination with the redundancy provided by

It’s a very small point, but I think it’s just a little harder to follow than
necessary because of two uses of “enable” with different senses — it’s easy to
read the first in the same sense as the second, “optional to enable” (rather
than “to enable an operator to...”).  I suggest changing the first to “allow”,
and maybe also change it slightly, so: “are optional, and allow an operator
to...”.

— Section 2.2 —
It’s usually not a good idea to have different definitions for things such as
“upstream” and “Upstream”, for one reason because they can’t be distinguished
if they begin a sentence (where they’ll both appear as “Upstream”), and for
another because it’s easy to inadvertently write the wrong one and not catch
it.  I checked, and I don’t see any case of the first in this document (where
“Upstream” appears at the beginning of the second bullet in Section 5 it seems
to be clear because of “downstream” in the other bullets), but you need to be
careful not to introduce that ambiguity during the editing process.  It would
be good for the AD to include an RFC Editor note to that effect, so they are
alerted to this situation and to avoid beginning any sentences with “Upstream”.
 And the authors should be sure to carefully check every instance of the word
during AUTH48 (it would be good for the RFC Editor to include a reminder of
that in the AUTH48 message).