[bess] Fwd: Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)

["Murray S. Kucherawy" <[e-mail]>]

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 <[e-mail]>
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) <[e-mail]>
Cc: The IESG <[e-mail]>rg>, Stephane Litkowski (slitkows) <
[e-mail]>gt;, [e-mail] <
[e-mail]>gt;, [e-mail] <
[e-mail]>gt;, [e-mail] <[e-mail]>rg>,
[e-mail] <[e-mail]>


On Wed, Nov 17, 2021 at 12:03 PM Mankamana Mishra (mankamis) <
[e-mail]> 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?

(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?

(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?

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.

-MSK

>