John Scudder has entered the following ballot position for draft-ietf-bess-evpn-irb-mcast-11: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document. Although dense and slow going, I appreciated the thoroughness and precision and have confidence that the dedicated reader who makes it all the way through will be able to implement this specification. I have some minor comments below that I hope might be of use. - I continue to find the profligate use of acronyms and initialisms that characterizes so many bess documents to be an unnecessary, not to say gratuitous, impediment to readability, but so it goes. (If the authors are open to what might be an extensive revision to address this, I'm willing to dig in and provide more detailed feedback. But I don't expect it, at this late stage, especially since as noted above, I do think the document is usable, my complaint notwithstanding. If I'm mistaken, let me know and we can work on it.) - I agree with Éric Vyncke that there are several places where the text could easily be elucidated with the use of a diagram. Essentially, any of the many (very welcome!) examples seems like an easy candidate, one instance being “Suppose a given Tenant Domain contains three BDs (BD1, BD2, BD3) and two PEs (PE1, PE2). PE1 attaches to BD1 and BD2, while PE2 attaches to BD2 and BD3.” - I'm sure the RFCEd will flag this, but consider replacing the pronoun "he" in Section 1.3 with something not gender-specific. - In Section 1.5.2 you mention an “attachment AC”, which expands as "attachment attachment circuit". Probably drop "attachment" or (better still in my view, see my first bullet) spell out "attachment circuit". - In Section 2.5 you have “This does assume that source S does not send the same (S,G) datagram on two different BDs, and that the Tenant Domain does not contain two or more sources with the same IP address S. The use of multicast sources that have IP "anycast" addresses is outside the scope of this document?” I tried to puzzle out what the consequence would be if that situation arose, but failed. Can you comment? _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
