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