Hi, Comments inline below.
Yours Irrespectively, John Juniper Business Use Only From: BESS <bess-boun...@ietf.org> On Behalf Of Murray S. Kucherawy Sent: Friday, March 11, 2022 11:41 PM To: BESS <bess@ietf.org>; bess-cha...@ietf.org Subject: [bess] Fwd: Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT) [External Email. Be cautious of content] Hi, I'd still like to clear up these points before I clear my DISCUSS. I see there's been some revision activity on the document, but these issues haven't been resolved yet. Thanks, -MSK ---------- Forwarded message --------- From: Murray S. Kucherawy <superu...@gmail.com<mailto:superu...@gmail.com>> Date: Thu, Dec 9, 2021 at 8:03 AM Subject: Re: Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT) To: Mankamana Mishra (mankamis) <manka...@cisco.com<mailto:manka...@cisco.com>> Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>, Stephane Litkowski (slitkows) <slitk...@cisco.com<mailto:slitk...@cisco.com>>, draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org<mailto:draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org> <draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org<mailto:draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>>, bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com> <slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>> On Wed, Nov 17, 2021 at 12:03 PM Mankamana Mishra (mankamis) <manka...@cisco.com<mailto:manka...@cisco.com>> wrote: (0) I suggest making each of the actions you want to take (there are four) into their own subsections of this section. Any thoughts on this point? [JD] We'll have four subsections (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. ...or this one? [JD] Okay (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. Well, BCP 26 says they both should. It's unfortunate the other registry doesn't, but is that a good reason not to add one here? [JD] We will follow the guidance of IANA, which was always our intention Section 3 defines "NV" and "NVO", but these terms appear nowhere in the document. Thanks for fixing this. 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 ? If the point is just to give choices, then I suggest you consider using MAY. SHOULD is defined to mean "Do this unless you have a really good reason not to", and in those cases, the document serves the reader better if it gives some guidance as to why an implementer might do something other than what it says. [JD] I reviewed each instance of the use of SHOULD and I thought they all seemed appropriate -MSK
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
