Re: [bess] Francesca Palombini's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)

["Mankamana Mishra (mankamis)" <[e-mail]>]

Hi Francesca
Thanks for comment. I apologies for missing this email.   Please find inline comment.

Mankamana

From: Francesca Palombini via Datatracker <[e-mail]>
Date: Thursday, October 28, 2021 at 7:12 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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