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

[John E Drake <[e-mail]>]

Hi,

Snipped, comments inline below,

Yours Irrespectively,

John



Juniper Business Use Only
From: Murray S. Kucherawy <[e-mail]>
Sent: Saturday, March 12, 2022 1:17 PM
To: John E Drake <[e-mail]>
Cc: BESS <[e-mail]>rg>; [e-mail]; Mankamana Mishra (mankamis) <[e-mail]>om>; Ali Sajassi (sajassi) ([e-mail]) <[e-mail]>
Subject: Re: [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]

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.

[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