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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 11 Mar 2022 20:41:08 -0800

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 <[email-masked]>
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) <[email-masked]>
Cc: The IESG <[email-masked]>, Stephane Litkowski (slitkows) <
[email-masked]>, [email-masked] <
[email-masked]>, [email-masked] <
[email-masked]>, [email-masked] <[email-masked]>,
[email-masked] <[email-masked]>

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

---

From: John E Drake <[email-masked]>
Date: Sat, 12 Mar 2022 15:00:41 +0000

Hi,

Comments inline below.

Yours Irrespectively,

John

Juniper Business Use Only
From: BESS <[email-masked]> On Behalf Of Murray S. Kucherawy
Sent: Friday, March 11, 2022 11:41 PM
To: BESS <[email-masked]>; [email-masked]
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 <[email-masked]<mailto:[email-masked]>>
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) <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>, Stephane Litkowski (slitkows) <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

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

[JD]  We'll have four subsections

...or this one?

[JD]  Okay

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Mar 2022 10:17:22 -0800

On Sat, Mar 12, 2022 at 7:00 AM John E Drake <[email-masked]> wrote:

> *From:* BESS <[email-masked]> *On Behalf Of * Murray S. Kucherawy
> *Sent:* Friday, March 11, 2022 11:41 PM
> *To:* BESS <[email-masked]>; [email-masked]
> *Subject:* [bess] Fwd: Murray Kucherawy's Discuss on
> *[External Email. Be cautious of content]*
>
>
>
> From: *Murray S. Kucherawy* <[email-masked]>
> *[JD]  We’ll have four subsections*
>

> *[JD]  Okay*

I think this one was fixed in -14 already.

> *[JD]  We will follow the guidance of IANA, which was always our intention
> *
>

OK, I'll watch for a change here.

> *[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

---

From: John E Drake <[email-masked]>
Date: Mon, 14 Mar 2022 15:03:57 +0000

Hi,

Snipped, comments inline below,

Yours Irrespectively,

John

Juniper Business Use Only
From: Murray S. Kucherawy <[email-masked]>
Sent: Saturday, March 12, 2022 1:17 PM
To: John E Drake <[email-masked]>
Cc: BESS <[email-masked]>; [email-masked]; Mankamana Mishra (mankamis) <[email-masked]>; Ali Sajassi (sajassi) ([email-masked]) <[email-masked]>
Subject: Re: [bess] Fwd: Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)

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.

[JD]  We will change the SHOULD to a MUST in section 7

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?

[JD]  We will change the SHOULD to a MUST in sections 9.1 and 9.1.3.  The SHOULD in sections 9.1.1, 9.2.1, and 9.3.1 are fine;  there are RDs of other types and everything will work if they are used but type 1 is preferred because it provides the address of the route originator.  If you would like, we can add this explanation to those sections

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Mar 2022 21:42:43 -0700

On Mon, Mar 14, 2022 at 8:04 AM John E Drake <[email-masked]> wrote:

>
>
> *[JD]  We will change the SHOULD to a MUST in sections 9.1 and 9.1.3.  The
> SHOULD in sections 9.1.1, 9.2.1, and 9.3.1 are fine;  there are RDs of
> other types and everything will work if they are used but type 1 is
> preferred because it provides the address of the route originator.  If you
> would like, we can add this explanation to those sections       *
>
>
>

Yes, that would be ideal.  Thanks!

-MSK

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Mon, 21 Mar 2022 16:42:49 +0000

Thanks Murray for comment. Attached diff is being published in next 15 min (sorry tool has some issue, so upload is failing).

It address your comment .

From: Murray S. Kucherawy <[email-masked]>
Date: Monday, March 14, 2022 at 9:43 PM
To: John E Drake <[email-masked]>
Cc: BESS <[email-masked]>, [email-masked] <[email-masked]>, Mankamana Mishra (mankamis) <[email-masked]>, Ali Sajassi (sajassi) <[email-masked]>
Subject: Re: [bess] Fwd: Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)
On Mon, Mar 14, 2022 at 8:04 AM John E Drake <[email-masked]<mailto:[email-masked]>> wrote:

-MSK