Mike, We have posted revision 26 with revised structure which I hope makes the document easier to read and follow.
Thanks, Rishabh On Tue, Oct 21, 2025 at 8:07 AM Rishabh Parekh <[email protected]> wrote: > Mike, > We are in the process of re-organizing and reworking drafts based on other > reviews. I hope it improves the readability of the document. > > Thanks, > Rishabh. > > On Mon, Oct 20, 2025 at 2:00 PM Mike Bishop via Datatracker < > [email protected]> wrote: > >> Mike Bishop has entered the following ballot position for >> draft-ietf-bess-mvpn-evpn-sr-p2mp-15: No Record >> >> 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-mvpn-evpn-sr-p2mp/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> This draft is very difficult to approach for anyone who isn't a domain >> expert. >> It uses a lot of domain-specific terminology even before you get to the >> list of >> RFCs whose terminology the reader is expected to be familiar with. That >> paragraph points to certain RFCs for "terms like" a list of items, >> suggesting >> that there might be other referenced terms in any given document with no >> pointer here. That makes it difficult for the reader to take an >> unfamiliar term >> and look it up. >> >> I would encourage the authors to rework the introduction to contain a >> simple >> problem statement, an overview of how the existing technologies currently >> handle it, and what this document defines to improve the situation. Some >> diagrams might also be helpful in articulating the framework. I would >> suggest >> that this also include a thorough terminology section that cites RFCs >> and/or >> defines terms as appropriate for the reader attempting to consume this >> document. >> >> In the Introduction, there's no reference cited for "P2MP Ingress >> Replication". >> Searching online for that phrase finds this draft as the primary hit. I >> assume >> that's intended to point to Section 6.4.5 of RFC 6513? >> >> Throughout, the draft is inconsistent about using "a SR" or "an SR" -- >> which is >> correct turns on whether "SR" is pronounced "source routing" or "ess arr". >> Please pick one. >> >> For the moment, I'm intentionally balloting "No Record," because I'd like >> the >> authors to have this feedback now. It's going to take me some time to >> read this >> in more depth and update my ballot position. >> >> >> >> _______________________________________________ >> BESS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
