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

[Murray Kucherawy via Datatracker <[e-mail]>]

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?