Hi Murray, Thanks for comment . Please find inlinecomment. From: Murray Kucherawy via Datatracker <nore...@ietf.org> Date: Wednesday, October 27, 2021 at 11:34 PM To: The IESG <i...@ietf.org> Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org <draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, slitkows.i...@gmail.com <slitkows.i...@gmail.com> Subject: Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT) Murray Kucherawy has entered the following ballot position for draft-ietf-bess-evpn-igmp-mld-proxy-14: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There's an IPR disclosure on this document. In the shepherd writeup, where a summary of the discussion of it is requested, it simply says "There are 3 IPRs disclosed". I'd like to hear that summary, or at least confirm the discussion was had and there were no concerns as a result. Mankamana : @Stephane Litkowski (slitkows)<mailto:slitk...@cisco.com> to address this comment. The IANA Considerations section needs some work: (0) I suggest making each of the actions you want to take (there are four) into their own subsections of this section. (1) "EVPN Extended Community sub-types registry" should be "EVPN Extended Community Sub-Types sub-registry of the BGP Extended Communities registry", which makes it easier to find. (2) "Multicast Flags Extended Community" appears to be a new registry you're creating in the final action here. BCP 26, for a First Come First Served registry, advises that a change controller column be included. Are you intentionally omitting this here? Or if this is referring to an existing registry, I wasn't able to find it. Mankamana :The registry in (1), above, is also FCFS and it does not have a change controller column. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3 defines "NV" and "NVO", but these terms appear nowhere in the document. Every SHOULD in this document, other than the ones that talk about logging, left me wondering why an implementer might decide not to follow that advice. Since SHOULD presents a choice, I suggest including some guidance about why it's a SHOULD, i.e., when one might decide not to do what it says and still expect to interoperate. Or should some of these really be MUSTs? Mankamana : My understanding should gives more flexibility to implementation to make choices. And may not be good idea to make every thing MUST until without it protocol breaks. Is there any specific instance which you want to make MUST ?
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
