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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 16 Dec 2020 21:20:11 -0800

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).

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 16 Dec 2020 21:42:56 -0800

Hi Barry,
thank you for the review, comments, and suggestions. Please find my
answers below tagged by GIM>>.

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/
GIM>> Many thanks for the suggestions. I agree with you and used the second
one to get the text as follows:
   The procedures described in this document are optional and allow an
   operator to provide protection for multicast services in BGP/MPLS IP
   VPNs.
> that in the AUTH48 message).
GIM>> Thank you for your thoughtful and forthlooking comment. At some
point, we had that ambiguity in the text. We will keep an eye out to keep
the document consistent.