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

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Wed, 8 Dec 2021 23:36:29 +0000

Hi Murray,
new version uploaded where  NV and NVO removed since they were not 
used.   Please let me know if you have any comment.

Mankamana

On 11/22/21 2:14 AM, [email-masked] wrote:
> Hi Murray,
>
>> 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.
>
> The WG didn't raised any concern about the IPR disclosed for this document.
>
> Brgds,
>
> Stephane
>
>
> -----Original Message-----
> From: Murray Kucherawy via Datatracker <[email-masked]>
> Sent: jeudi 28 octobre 2021 08:34
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> 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.
>
> 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.
>
>
> ----------------------------------------------------------------------
> 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?
>
>
>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Dec 2021 08:03:04 -0800

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