On Sat, Mar 12, 2022 at 7:00 AM John E Drake <jdr...@juniper.net> wrote:
> 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> > 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> > Cc: The IESG <i...@ietf.org>, Stephane Litkowski (slitkows) < > slitk...@cisco.com>, 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> > > > > On Wed, Nov 17, 2021 at 12:03 PM Mankamana Mishra (mankamis) < > 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* > I think this one was fixed in -14 already. > > (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 > * > OK, I'll watch for a change here. > 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 * > > > Only part of my question is about whether "SHOULD" is appropriate instead of "MUST". What I'm suggesting is some advice to the reader about when I might decide not to do what the SHOULD says. For example, consider the SHOULD in Section 7. You're giving the implementer a choice here. Can they decide to do something other than what it says for any legitimate reason and still interoperate? If yes, I would suggest including such a reason. If not, maybe SHOULD isn't actually right here. Similar point for the one at the end of Section 9.1, or the one in 9.1.1, or in 9.3.1. For the one at the end of 9.1.3, what other procedure might one decide to use, and why? -MSK
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
