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). _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
