[pim] Éric Vyncke's No Objection on draft-ietf-pim-igmp-mld-snooping-yang-17: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-pim-igmp-mld-snooping-yang-17: No Objection

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-snooping-yang/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. On an editorial note, I found
sometimes the text difficult to read (I am not an English-native speaker) due
to very long sentences: e.g., the first 2 paragraphs of section 2.2.

Please find below a couple of non-blocking COMMENTs (and I would appreciate a
reply to each of my COMMENTs).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
I am not a big expert in MLD or WiFi, but, it seems to me that this YANG module
covers only the important use case of switches. But, if not mistaken, some WiFi
access points also do a similar job and translates L2 mcast addresses into a
series of L2 unicast addresses. Was it considered in this model ?

-- Section 1.1 --
English is not my native language, but, I have hard time to parse "mrouter:
multicast router, which means nodes attached to a switch have multicast routing
enabled" is a switch or a router ?

-- Section 2.3 --
No need to reply on this one, but, I really do not like separating the IPv4 and
IPv6 branches of the trees. It looks to me like doubling the operational cost
but not sharing common properties; hence, diminishing the usefulness of this
document. I made the same comment for RFC 8652 and there is really no need to
repeat what I consider as mistakes.

-- Section 4 --
The description parts of the YANG module are quite short so I may have
overlooked some parts of it... so bear with my two COMMENTs below:

1) for a MLD group, why having the mac-address leaf ? AFAIK, the mac-address is
derived from the group IPv6 mcast address. Storing related information twice in
a model looks bad to me (I am a big fan of the SQL normal forms...)

2) some switches does not snoop MLD for link-local groups (sollicited node
mcast for example). Is this feature listed in the list of features ?