Hi Francesca Thanks for comment. I apologies for missing this email. Please find inline comment.
Mankamana From: Francesca Palombini via Datatracker <[email protected]> Date: Thursday, October 28, 2021 at 7:12 AM To: The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Francesca Palombini's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT) Francesca Palombini has entered the following ballot position for draft-ietf-bess-evpn-igmp-mld-proxy-14: 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/blog/handling-iesg-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-igmp-mld-proxy/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work on this document. As in draft-ietf-bess-evpn-optimized-ir, I have to comment on the overuse of abbreviations and the assumptions that the reader is familiar with all concepts and terms used make the document really hard to read for non-expert in the field. I'll also point out that having a terminology section with expansion but with no references is not as useful as one with proper descriptions and references. Mankamana : This document builds on top of RFC7432. And does use many terminology from basic multicast. Adding all possible terminology may be overkill for draft. Please let me know if any thing specific is missing. Here as well, there is a several uses of SHOULD and should in a way that either is requiring more context (what are the conditions when it is acceptable to not follow the SHOULD recommendations): o Reserved bits MUST be set to 0 by sender. And receiver SHOULD ignore the Reserved bits. and cases where IMO the term would better be replaced by something else, possibly more descriptive: Mankamana: Please let me know if you looking for specific description here. > The registration policy should be "First Come First Served". > The registry should be initialized as follows: Mankamana : There was comment during WG discussion and it was decided to keep it as “FCFS” I don't have any other comment that has not already been flagged by my fellow ADs: I scanned for ART issues but did not find any significant ones. (Please do fix Lars non-blocking points as well). Francesca
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
