[bess] John Scudder's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

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?