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

[Greg Mirsky <[e-mail]>]

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

Regards,
Greg

On Wed, Dec 16, 2020 at 9:20 PM Barry Leiba via Datatracker <
[e-mail]> wrote:

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