Hi, 

I reviewed this document as part of the Internet Directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the Internet Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments.


Disclaimer: I lack expertise in multicast; therefore, I kindly ask you to consider my remarks with a grain of salt.

Yours, 
Daniel


1.  Introduction

   For IPv6 multicast addresses, Section 2 of [RFC3307] defines the
   lower 32 bits of the IPv6 address, which are mapped directly to the
   link-layer, as the group ID, and then assigns ranges of group ID
   values based on how they are allocated.  
   
I believe the sentence could be clearer, particularly for readers who are not well-versed in the topic of multicast, which applies to my situation. Upon briefly reviewing 3307, I do not observe a normative MUST that binds IPv6 to the link-layer, leading me to question whether this is merely a convenience or an obligation. I suspect that once the multicast destination IPv6 address is constructed, the last four bytes identify the Group ID, which is then utilized to form the 33-33-group ID multicast Ethernet destination address. Dividing the text into multiple sentences aids in comprehension, as terms like 'mapping' can be more confusing than 'copied', for instance.

My understanding is that multicast IP addresses are defined in 3306, featuring a flag field composed of two bits (T and P). According to 2373, T=1 signifies a permanent multicast IP address, while T=0 indicates that the multicast IP address is not permanent. I perceive a distinction between the group ID and IP addresses. I suspect that the P flag is intended to clarify the relationship between the network prefix and the group ID. When the Group ID is associated with the network prefix, which I understand cannot be used independently, P is set to 1. Conversely, P=0 could imply a group ID that may be shared across different network prefixes. At this juncture, I find it somewhat unclear what the value of P would be for a private network concerning a specific group ID. I would be interested in obtaining that information for my personal knowledge.


2.  Considerations for Source-Specific Multicast


   However, SSM is not universally supported ([RFC4607], Section 6 lists
   one example).  This document defines a range of dynamic IPv6
   multicast group IDs for use in environments that do support SSM.

I have the impression that the initial sentence may be omitted. It gives the impression that we are defining a refinement of something that is not universally utilized. I might be overlooking something, but if there is a connection between the two sentences, I would recommend that it be explicitly mentioned.

I believe it would be beneficial to outline the advantages or motivations for partitioning the Group IDs.

This may be a naive question, but I am curious as to why the environment should uniformly support MSS or not support it. More specifically, I am inquiring whether we could have a mix of nodes that support SSM and those that do not. In our situation, I am also contemplating the potential consequences of a host supporting SSM according to the conventions defined in this document, alongside hosts that support the previous version of SSM. This topic might be worth discussing in the security considerations section as well.