[pim] Re: Mohamed Boucadair's Discuss on draft-ietf-pim-up dt-ipv6-dyn-mcast-addr-grp-id-10: (with DISCUSS and COMMENT )

Med,

Thanks! A new version has been posted to address your additional feedback:

https://datatracker.ietf.org/doc/draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id/

My replies are below, marked [Karstens].

Nate

From: [email protected] <[email protected]>
Sent: Friday, February 27, 2026 01:51
To: Karstens, Nate <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; The IESG <[email protected]>
Subject: RE: [pim] Mohamed Boucadair's Discuss on draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-10: (with DISCUSS and COMMENT)

Hi Nate, Thank you for the follow-up and changes made so far. These are heading in a good direction. Please see inline. Cheers, Med De : Karstens, Nate <Nate. Karstens@ garmin. com> Envoyé : vendredi 27 février 2026 06: 19 À : BOUCADAIR Mohamed

Hi Nate,

Thank you for the follow-up and changes made so far. These are heading in a good direction.

Please see inline.

Cheers,
Med

De : Karstens, Nate <[email protected]<mailto:[email protected]>>
Envoyé : vendredi 27 février 2026 06:19
À : BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>>
Cc : [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Objet : RE: [pim] Mohamed Boucadair's Discuss on draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-10: (with DISCUSS and COMMENT)

Med,

Thanks for your review! We posted v11 to address your feedback:

https://datatracker.ietf.org/doc/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!VriYdC6P_RTjFBC0wdqslPJhhzepg_AXSdrtVD6u3A9OYJ-AEVLjtJqBdOYVDSW-EGEY9vmFIit-anadWA6X7hYDr4yjlg$>

My comments are below marked [Karstens].

Cheers,

Nate

From: Mohamed Boucadair via Datatracker <[email protected]<mailto:[email protected]>>
Sent: Tuesday, February 24, 2026 01:02
To: The IESG <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: [pim] Mohamed Boucadair's Discuss on draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-10: (with DISCUSS and COMMENT)

Mohamed Boucadair has entered the following ballot position for draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. 


Mohamed Boucadair has entered the following ballot position for

draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-10: 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!TSFSnIPoAWnJ8qdK0FDAS5SCxjYb2bbIzh35WNV95FCt-G-6Bw806AMtq-oaP3mIAzcIoqlRJbe2EpYyJw$<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!EJc4YC3iFmQ!TSFSnIPoAWnJ8qdK0FDAS5SCxjYb2bbIzh35WNV95FCt-G-6Bw806AMtq-oaP3mIAzcIoqlRJbe2EpYyJw$>

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-updt-ipv6-dyn-mcast-addr-grp-id/__;!!EJc4YC3iFmQ!TSFSnIPoAWnJ8qdK0FDAS5SCxjYb2bbIzh35WNV95FCt-G-6Bw806AMtq-oaP3mIAzcIoqlRJbd1Sxse8w$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id/__;!!EJc4YC3iFmQ!TSFSnIPoAWnJ8qdK0FDAS5SCxjYb2bbIzh35WNV95FCt-G-6Bw806AMtq-oaP3mIAzcIoqlRJbd1Sxse8w$>







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

DISCUSS:

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



Hi Nate, Dino, and Mike,



Thank you for the effort put into this document.



Thank you to Dhruv Dhody for the OPSDIR review and for the authors for engaging

and addressing the review.



Please find below some points for DISCUSSion:



# Be explicit about the update to 3307



Can we please indicate what is updated in 3307 and how one should interpret

this?



For example, can we say that we update Section 4.3 of 3307 as follows



OLD:

Dynamic IPv6 multicast addresses can be allocated by an allocation server or by

an end-host.



NEW:

Dynamic IPv6 multicast addresses can be allocated by an allocation server, an

end-host, or coordinated via a global registry (e.g., IANA-maintained registry).



[Karstens] We modified the last paragraph of the introduction to be more explicit. I think your example was meant to illustrate that we can call out specific text that is being updated. The nature of the update does not lend itself to text substitution, but hopefully this makes it apparent what about RFC 3307 needs to be updated.

[Med] I like the changes made here. This would be even better if we can be clearer on what “additional dynamic allocation protocols may be developed” are allowed with the changes, while this is not allowed by base 3307. Can we have some more words among those lines?

[Karstens] We extended this paragraph to highlight that the changes will allow multiple dynamic allocation protocols to coexist. Put in context: the first paragraph mentions RFC 3307 prevents coexistence due to potential address collisions and the second paragraph mentions that the changes will allow coexistence. Hopefully this is along the lines of what you were looking for 😊.



# De we need a range for experimentations?



CURRENT:

    +-----------------------+-----------------+-----------------------+

    | 0xFE000000-0xFEFFFFFF | Private Use     | [This document]       |

    +-----------------------+-----------------+-----------------------+



As SSM is the recommended inter-domain case (and putting aside real deployment

cases): shouldn’t there be a range for experimentation? Such use doesn’t fall

under private use.



[Karstens] We didn’t anticipate a long-term need that couldn’t be satisfied by temporary use of the Private Use range (according to RFC 8126, neither Private Use nor Experimental Use ranges are registered). If you feel strongly then we can add a range for Experimental Use.

[Med] I would add one as this would be cleaner. Thank you. When adding that range, please add a statement to say that there is no restriction to use those over Internet.



FWIW, RFC8126 says:

   When code points are set aside for Experimental Use, it's important

   to make clear any expected restrictions on experimental scope.  For

   example, say whether it's acceptable to run experiments using those

   code points over the open Internet or whether such experiments should

   be confined to more closed environments.

[Karstens] Done!



# Operational Impact and Backward Compatibility



CURRENT:

   This reduces the range previously available for MADCAP, while still

   providing a sizable allocation.



A key point missing in the spec is the backward compatibility of the changes.



Please add a discussion to a NEW Operational Considerations Section whether

this is an issue or not.



More generally, I’d hope we can have a discussion recorded here about what are

the implications of this changes, discuss if there is anything that is broken

or all is OK (if so, say it explicitly there).



The use of the group ids is not impacted. Maybe indicate how the new mode will

work/expected to work.



[Karstens] No problem, we added this in the new version, please let us know if you have any suggestions. We had a discussion with Dave Thaler about this (see Acknowledgement section), but documenting recommendations is a good idea.

[Med] Thank you for the new section.



# IANA Actions



## Clarity



CURRENT:

   The "Standards Action" registration policy is required to update the

   registry.



I guess you meant only 0x90000000-0xEFFFFFFF range, not all any entry in the

table. Please check.



[Karstens] I think we would want to apply standards action to the whole table. Certainly assigning a new entry would require a standard. Modifying existing entries would be modifying a standard (e.g., this document, MADCAP, or RFC 4291), so would also require a standard. But if you think something else would work better I’m open to suggestions.

[Med] You are right. I think we are OK for this one.



## Please s/MUST/must in the following per the guidance in

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/__;!!EJc4YC3iFmQ!TSFSnIPoAWnJ8qdK0FDAS5SCxjYb2bbIzh35WNV95FCt-G-6Bw806AMtq-oaP3mIAzcIoqlRJbcBHB4enQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/__;!!EJc4YC3iFmQ!TSFSnIPoAWnJ8qdK0FDAS5SCxjYb2bbIzh35WNV95FCt-G-6Bw806AMtq-oaP3mIAzcIoqlRJbcBHB4enQ$>

(Inappropriate Uses of Key Words ).



CURRENT:

       Values MUST be

       within the range for dynamic multicast address allocation

       mechanisms specified in [RFC3307]: 0x80000000 to 0xFFFFFFFF.



[Karstens] Done!

[Med] ACK



## RFC3307 as an additional reference to the new registry



Rather than having the text above under the range value, I think that this is

better if this is placed as a note in the registry itself + add 3307 as an

additional reference to the registry.



[Karstens] Good idea, done!

[Med] ACK



# Normative specification



CURRENT:

7.2.  Informative References



   [RFC2730]  Hanna, S., Patel, B., and M. Shah, "Multicast Address

              Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,

              DOI 10.17487/RFC2730, December 1999,

              <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc2730__;!!EJc4YC3iFmQ!TSFSnIPoAWnJ8qdK0FDAS5SCxjYb2bbIzh35WNV95FCt-G-6Bw806AMtq-oaP3mIAzcIoqlRJbc0AYRx0w$<https://urldefense.com/v3/__https:/www.rfc-editor.org/info/rfc2730__;!!EJc4YC3iFmQ!TSFSnIPoAWnJ8qdK0FDAS5SCxjYb2bbIzh35WNV95FCt-G-6Bw806AMtq-oaP3mIAzcIoqlRJbc0AYRx0w$>>.



   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing

              Architecture", RFC 4291, DOI 10.17487/RFC4291, February

              2006, <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc4291__;!!EJc4YC3iFmQ!TSFSnIPoAWnJ8qdK0FDAS5SCxjYb2bbIzh35WNV95FCt-G-6Bw806AMtq-oaP3mIAzcIoqlRJbcEKXpOmQ$<https://urldefense.com/v3/__https:/www.rfc-editor.org/info/rfc4291__;!!EJc4YC3iFmQ!TSFSnIPoAWnJ8qdK0FDAS5SCxjYb2bbIzh35WNV95FCt-G-6Bw806AMtq-oaP3mIAzcIoqlRJbcEKXpOmQ$>>.



   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for

              IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,

              <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc4607__;!!EJc4YC3iFmQ!TSFSnIPoAWnJ8qdK0FDAS5SCxjYb2bbIzh35WNV95FCt-G-6Bw806AMtq-oaP3mIAzcIoqlRJbd6Rl1brA$<https://urldefense.com/v3/__https:/www.rfc-editor.org/info/rfc4607__;!!EJc4YC3iFmQ!TSFSnIPoAWnJ8qdK0FDAS5SCxjYb2bbIzh35WNV95FCt-G-6Bw806AMtq-oaP3mIAzcIoqlRJbd6Rl1brA$>>.



## 2730 is normative IMO to assess the impact of the change on MADCAP.



## 4291 is needed for Solicited-Node multicast



## 4607: I’m less sure about this one, but this is the only reference we have

here for SSM. A normative reference for SSM is needed, otherwise.



[Karstens] These have all been made normative.

[Med] Thanks



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

COMMENT:

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



# General: Correct Registry Name



Please update “IPv6 Multicast Address Space Registry” registry to “IPv6

Multicast Address Space” to use the exact name as maintained by IANA:

https://urldefense.com/v3/__https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml__;!!EJc4YC3iFmQ!TSFSnIPoAWnJ8qdK0FDAS5SCxjYb2bbIzh35WNV95FCt-G-6Bw806AMtq-oaP3mIAzcIoqlRJbeCTJHXyg$<https://urldefense.com/v3/__https:/www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml__;!!EJc4YC3iFmQ!TSFSnIPoAWnJ8qdK0FDAS5SCxjYb2bbIzh35WNV95FCt-G-6Bw806AMtq-oaP3mIAzcIoqlRJbeCTJHXyg$>



[Karstens] Good suggestion, done!

[Med] ACK



# Abstract



## Add title of RFC cited in the abstract so that we have a self-contained

abstract per the following guidance:



   An Abstract is not a substitute for an Introduction; the RFC should

   be self-contained as if there were no Abstract.  Similarly, the

   Abstract should be complete in itself.  Given that the Abstract will

   appear independently in announcements and indices, uncommon

   abbreviations should be expanded, and mentions of other RFCs within

   the Abstract should include both an RFC number and either the full or

   short title.



[Karstens] Done!

[Med] ACK



## s/suggests/defines



[Karstens] Done!

[Med] ACK



# IPv6 Multicast Address Architecture



## I would add a pointer to the multicast address architecture (RFC7371), as

that with 4291 are where to look for these matters. This would help set a

context for where “global id” intervenes in an IPv6 multicast address.



## Also, I suggest we add a mention that this document adheres to that

architecture



[Karstens] RFC 7371 seems to be related to IPv6 multicast flag bits. Is there a different RFC you’re thinking of?

[Med] I was referring to cite both 4291/7371 as these provides the internal structure of multicast @es. The clarifications out there are about SSM ranges are also useful. Leave it to you to cites those and say that the doc adheres to the IPv6 mcast architecture.

[Karstens] We added a third paragraph to the Introduction, does this work?



# Section 2



## No network-wide coordination



CURRENT:

   This reduces

   the need for coordinated dynamic assignment of G because multiple

   distinct hosts could use the same value for G and traffic would still

   be directed to the node that requested the stream.



Maybe add a pointer as well to the rfc8815#section-3.2.2 (BCP 229) as it

discusses that specific point. This would back this statement.



[Karstens] Great addition, done!

[Med] ACK



## SSM Deployment



CURRENT:

   However, SSM is not universally supported ([RFC4607], Section 6 lists

   one example).



I would refer to rfc8815#section-3.1 as it is more recent than 4607 and reflect

more recent deployment status.



[Karstens] Done!

[Med] ACK



# nits



[Karstens] All nits done!

[Med] Thank you.



## Abstract



OLD: allocations with a new registry in



NEW: allocations with a new IANA registry in



## Introduction



OLD: Only one server allocation protocol has been defined so far



NEW:    Only one server allocation protocol has been defined at the time of

writing



## IANA



OLD: IANA should create



NEW: This document requests IANA to create



Please let me know if any clarification is needed.



Cheers,

Med







_______________________________________________

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.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

________________________________

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]