[pim] Re: Éric Vyncke's Discuss on draft-ietf-pim-zer oconf-mcast-addr-alloc-ps-08: (with DISCUSS and COMMENT)

Hello Nate,

Thanks for your message. The revision -10 addresses all my blocking DISCUSS points, I will shortly clear my DISCUSS even if the text about MAC addresses length is rather light (i.e., with 16-bit MAC addresses there might be more requirements)

Regards

-éric


From: Karstens, Nate <[email protected]>
Date: Thursday, 20 November 2025 at 07:56
To: Eric Vyncke (evyncke) <[email protected]>, The IESG <[email protected]>
Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>
Subject: RE: [pim] Éric Vyncke's Discuss on draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08: (with DISCUSS and COMMENT)

Éric,

Thanks for your review! We uploaded draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-09 and made changes based on your feedback:

> Limited to 48-bit MAC addresses ?

We added the following note to the end of the IPv6 Considerations section:

Note that RFC3307 focuses on 48-bit addresses on Ethernet, but similar issues would be seen on any medium that generates link-layer multicast addresses by truncating an IPv6 multicast address.

> `Support for Unprivileged Applications`, this is not really something that it within IETF remit nor clear. Please rephrase.

We removed the entry from the list.

> `A solution to these issues is presented in [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id].` this sentence has no logical place in a *requirements* document. Please remove it.

In case it is helpful, this problem statement document is the first in a series of documents all designed to improve dynamic multicast address allocation. The three document that follow it are:


  *   draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id/__;!!EJc4YC3iFmQ!Ur-WB42q2Upf-OLknZHUAz6hVVJDwuLePYJrE5KWRIq-V7BOXNo07p73YWVcIKCWNjH03YR2ti1a8VrtpiTCjAcjCnrvjl9W6Q$>
  *   draft-ietf-pim-ipv6-zeroconf-assignment<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-ipv6-zeroconf-assignment/__;!!EJc4YC3iFmQ!Ur-WB42q2Upf-OLknZHUAz6hVVJDwuLePYJrE5KWRIq-V7BOXNo07p73YWVcIKCWNjH03YR2ti1a8VrtpiTCjAcjCnrsOmpFMA$>
  *   draft-ietf-pim-gaap<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-gaap/__;!!EJc4YC3iFmQ!Ur-WB42q2Upf-OLknZHUAz6hVVJDwuLePYJrE5KWRIq-V7BOXNo07p73YWVcIKCWNjH03YR2ti1a8VrtpiTCjAcjCnozr1IlZw$>

Our concern with removing the reference from the IPv6 considerations section is that the reader may get the impression that there is no solution to the issues we describe. Therefore, it seemed appropriate to point to this document. We could remove the reference and mention that the issues will be resolved in a subsequent document, though that would require the reader to locate that document themselves.

Please note that Ketan Talaulikar had a similar comment.

> Why limiting to Ethernet (i.e., not considering Wi-Fi) in `many Ethernet interfaces allow filtering` ?

Ketan Talaulikar had a similar point. We removed a few references to Ethernet and made it clear that other references were examples.

> Unsure whether the low-cost switches limitations should be a basis for a requirements at the IETF. Consider removing the paragraph starting with `Third, the internal design of some switches`. Especially, in the marine use case where the overal cost of the ship is much bigger than a normal switch ;-)

Ha, you’ve noticed that boats can be a little expensive :). We work primarily in the recreational marine market, so cost structures are different compared to something like a cruise ship.

The reference to low-cost switches was meant to explain why SSM is not an option. The switch described in the third example of address collisions is not necessarily limited to low-cost switches: there may be low-cost switches that have more flexible address tables, or expensive switches that include this limitation so that they can meet spec for the time it takes to look up an address. We thought it was an interesting example, and very much still relevant in today’s market.

> If this I-D will be the basis for solution protocols, then I *STRONGLY* advise to number the requirements for easier reference by other documents, e.g., REQ-n for the "shall" or CONS-n for the "should"

Good idea, done!

> s/section 2 of *this* RFC /section 2 of RFC *3307*/ let's be clear ;-)

Fixed!

> More important, why not specifying a requirement for this consideration ?

If I’m understanding your question, it’s because this is a structural issue that needs to be addressed with an update to RFC 3307, which is done by draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id/__;!!EJc4YC3iFmQ!Ur-WB42q2Upf-OLknZHUAz6hVVJDwuLePYJrE5KWRIq-V7BOXNo07p73YWVcIKCWNjH03YR2ti1a8VrtpiTCjAcjCnrvjl9W6Q$>. The protocol requirements are for the protocols described in draft-ietf-pim-ipv6-zeroconf-assignment<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-ipv6-zeroconf-assignment/__;!!EJc4YC3iFmQ!Ur-WB42q2Upf-OLknZHUAz6hVVJDwuLePYJrE5KWRIq-V7BOXNo07p73YWVcIKCWNjH03YR2ti1a8VrtpiTCjAcjCnrsOmpFMA$> and draft-ietf-pim-gaap<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-gaap/__;!!EJc4YC3iFmQ!Ur-WB42q2Upf-OLknZHUAz6hVVJDwuLePYJrE5KWRIq-V7BOXNo07p73YWVcIKCWNjH03YR2ti1a8VrtpiTCjAcjCnozr1IlZw$>.

> In `the protocol should try` it is (somehow) unclear what is 'the protocol' and also why not using BCP14 "SHOULD" rather "should" to align with section 3 ?

Done!

> Finally, why not specifying a requirement for this consideration ?

Our assessment is that the design of IPv4 makes dynamic multicast addressing very difficult, which is why our recommendation is to use IPv6.

> Like Paul's IESG and Joe's secdir review, this section should rather list security requirement(s) and probably use BCP14 terms.

I think their review was using the contents of the -07 document, but it was updated (hopefully improved) in the -08 version. It does not add requirements, but points out that specifics are outside the scope of this document.

We updated to use BCP14 terms.

Best Regards,

Nate

From: Éric Vyncke via Datatracker <[email protected]>
Sent: Wednesday, November 19, 2025 06:48
To: The IESG <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]
Subject: [pim] Éric Vyncke's Discuss on draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08: (with DISCUSS and COMMENT)

Éric Vyncke has entered the following ballot position for draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free

Éric Vyncke has entered the following ballot position for

draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!EJc4YC3iFmQ!U4rjjoJzKlwwyY2CrklHWAcsWkkQPxCEUFw2Z-SqpeZd54fO6VIMTj8n1BuCpii9icl_zSpAAwfde_i53A$<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!EJc4YC3iFmQ!U4rjjoJzKlwwyY2CrklHWAcsWkkQPxCEUFw2Z-SqpeZd54fO6VIMTj8n1BuCpii9icl_zSpAAwfde_i53A$>

for more information about how to handle DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/__;!!EJc4YC3iFmQ!U4rjjoJzKlwwyY2CrklHWAcsWkkQPxCEUFw2Z-SqpeZd54fO6VIMTj8n1BuCpii9icl_zSpAAwd4ncLojQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/__;!!EJc4YC3iFmQ!U4rjjoJzKlwwyY2CrklHWAcsWkkQPxCEUFw2Z-SqpeZd54fO6VIMTj8n1BuCpii9icl_zSpAAwd4ncLojQ$>







----------------------------------------------------------------------

DISCUSS:

----------------------------------------------------------------------





# Éric Vyncke, INT AD, comments for

draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08 CC @evyncke



Thank you for the work put into this document, solutions based on this set of

requirements would be useful indeed.



Please find below some blocking DISCUSS points, some non-blocking COMMENT

points/nits (replies would be appreciated even if only for my own education).



Special thanks to Stig Venaas for the shepherd's detailed write-up including

the WG consensus and the justification of the intended status.



Other thanks to Benson Muite, the Internet directorate reviewer (at my

request), please consider this int-dir review:

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/review-ietf-pim-zeroconf-mcast-addr-alloc-ps-07-intdir-telechat-muite-2025-11-11/__;!!EJc4YC3iFmQ!U4rjjoJzKlwwyY2CrklHWAcsWkkQPxCEUFw2Z-SqpeZd54fO6VIMTj8n1BuCpii9icl_zSpAAwdftDbVjw$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/review-ietf-pim-zeroconf-mcast-addr-alloc-ps-07-intdir-telechat-muite-2025-11-11/__;!!EJc4YC3iFmQ!U4rjjoJzKlwwyY2CrklHWAcsWkkQPxCEUFw2Z-SqpeZd54fO6VIMTj8n1BuCpii9icl_zSpAAwdftDbVjw$>

(and I have read Nate's reply -- even if I would prefer, like Benton, use cases

beyond marine).



I hope that this review helps to improve the document,



Regards,



-éric



## DISCUSS (blocking)



As noted in

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/__;!!EJc4YC3iFmQ!U4rjjoJzKlwwyY2CrklHWAcsWkkQPxCEUFw2Z-SqpeZd54fO6VIMTj8n1BuCpii9icl_zSpAAwdcVpWOcg$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/__;!!EJc4YC3iFmQ!U4rjjoJzKlwwyY2CrklHWAcsWkkQPxCEUFw2Z-SqpeZd54fO6VIMTj8n1BuCpii9icl_zSpAAwdcVpWOcg$>,

a DISCUSS ballot is a request to have a discussion on the points below; I

really think that the document would be improved with a change here, but can be

convinced otherwise.



### Limited to 48-bit MAC addresses ?



It seems that this document only targets layer-2 with 48-bit MAC addresses,

ignored other data link (e.g., IEEE 802.15.4 with its 16 or 64-bit MAC

addresses, see RFC 4944).



The text must either be clear about this limitation (including in title &

abstract) or be modified to also include 16- and 64- bit MAC addresses.



### Section 3



`Support for Unprivileged Applications`, this is not really something that it

within IETF remit nor clear. Please rephrase.



### Section 4



`A solution to these issues is presented in

[I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id].` this sentence has no logical

place in a *requirements* document. Please remove it.





----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------





## COMMENTS (non-blocking)



### Section 2



Why limiting to Ethernet (i.e., not considering Wi-Fi) in `many Ethernet

interfaces allow filtering` ?



Unsure whether the low-cost switches limitations should be a basis for a

requirements at the IETF. Consider removing the paragraph starting with `Third,

the internal design of some switches`. Especially, in the marine use case where

the overal cost of the ship is much bigger than a normal switch ;-)



### Section 3



If this I-D will be the basis for solution protocols, then I *STRONGLY* advise

to number the requirements for easier reference by other documents, e.g., REQ-n

for the "shall" or CONS-n for the "should"



### Section 4



s/section 2 of *this* RFC /section 2 of RFC *3307*/ let's be clear ;-)



More important, why not specifying a requirement for this consideration ?



### Section 5



In `the protocol should try` it is (somehow) unclear what is 'the protocol' and

also why not using BCP14 "SHOULD" rather "should" to align with section 3 ?



Finally, why not specifying a requirement for this consideration ?



### Section 7



Like Paul's IESG and Joe's secdir review, this section should rather list

security requirement(s) and probably use BCP14 terms.







_______________________________________________

pim mailing list -- [email protected]<mailto:[email protected]>

To unsubscribe send an email to [email protected]<mailto:[email protected]>

________________________________

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.

_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]