Hi Brian, PIM WG, Thank you for the effort put into the document to maintain MLD specs. The scope of the bis is reasonable and adequately described in Appendix B.2. I would insist more early in the document that the main change is associating meaning with fields that are used to be reserved, though. Please find below some comments, fwiw. # General ## Ops considerations How to determine whether a received MLDv2 message is to be interpreted following the rules in the bis or 3810 (that is, the meaning is actually associated or not with what used to be a reserved bit)? ## Reserved vs. Unassigned I wonder whether the remaining “Reserved” field can be renamed to “Unassigned” to have a provision for future use. Otherwise, I’m assuming 8126 definition is followed here: Unassigned: Not currently assigned, and available for assignment via documented procedures. While it's generally clear that any values that are not registered are unassigned and available for assignment, it is sometimes useful to explicitly specify that situation. Note that this is distinctly different from "Reserved". Reserved: Not assigned and not available for assignment. Reserved values are held for special uses, such as to extend the namespace when it becomes exhausted. "Reserved" is also sometimes used to designate values that had been assigned but are no longer in use, keeping them set aside as long as other unassigned values are available. Note that this is distinctly different from "Unassigned". Reserved values can be released for assignment by the change controller for the registry (this is often the IESG, for registries created by RFCs in the IETF stream). ## IPv6 Address Representation Please update all the addresses in the document to be consistent with RFC 5952 (lower case, zero compression, etc.). For example, s/FF02::1/ff02::1 ## pre-RFC5378 work As RFC 3810 was published before 10 November 2008, we may need to include a disclaimer for pre-RFC5378 work (https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/) unless we obtain your approval to grant the BCP78 rights to the IETF Trust. Was there any action on that front to reach out the authors? # Introduction: ## nit OLD: This document uses SSM-aware to refer to systems that support Source- Specific Multicast (SSM) as defined in [RFC4607] NEW: This document uses SSM-aware to refer to systems that support Source- Specific Multicast (SSM) as defined in [RFC4607]. ## Changes since 3810 I would add the following to the Introduction for the reader’s convenience. NEW: Appendix B.2 lists the main changes since RFC3810. ## Boilerplate OLD: The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. NEW: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. # Section 5.1.6: ## ambiguous reference given that two flag types are defined in 3228bis OLD: Allocation of individual bits within the Flags field is described in [I-D.ietf-pim-3228bis]. NEW: Allocation of individual bits within the Flags field is described in Section 2.2 of [I-D.ietf-pim-3228bis]. ## Allocation is important, but what is key is the associated meaning. Please consider stating both. Thanks. # Section 5.2.1: nit OLD: The Reserved field are set to zero on transmission, and ignored on reception. NEW: The Reserved field is set to zero on transmission, and ignored on reception. # Section 5.2.3 ## ambiguous reference given that two flag types are defined in 3228bis OLD: Allocation of individual bits within the Flags field is described in [I-D.ietf-pim-3228bis]. NEW: Allocation of individual bits within the Flags field is described in Section 2.3 of [I-D.ietf-pim-3228bis]. ## Allocation is important, but what is key is the associated meaning. # Section 5.2.13: Saying the obvious CURRENT: An SSM-aware host SHOULD NOT send a MODE_IS_EXCLUDE record type for multicast addresses that fall within the SSM address range. .. An SSM- aware host SHOULD NOT send a CHANGE_TO_EXCLUDE_MODE record type for multicast addresses that fall within the SSM address range. Consider adding the implication of not fallowing these SHOULD NOTs. I see that 7.4 mirrors the behavior for the router, but still a SHOULD is used there as well. # Section 7.2.1: nit OLD: The exact handling of both the INCLUDE and EXCLUDE mode router state, according to the received reports, is presented in details in Section 7.4.1 and Section 7.4.2. NEW: The exact handling of both the INCLUDE and EXCLUDE mode router state, according to the received reports, is presented in details in Sections 7.4.1 and 7.4.2. (three similar occurrences in Sections 7.2.3) # Section 8.2.1: Current: An SSM-aware host that receives an MLDv1 General Query or MLDv1 Group Specific Query for a multicast address in the SSM range SHOULD log an error. It is RECOMMENDED that implementions provide a configuration option to disable use of Host Compatibility Mode to allow networks to operate only in SSM mode. This configuration option SHOULD be disabled by default. ## Any guidance about rate-limiting logging for the same error? ## I’m afraid the last part of the sentence is not clear as one may interpret it as the configuration knob is not supported at all. I suggest to make it explicit that you are talking about the knob’s default value. ## Some may object to the use of normative language for the local configuration. I think it is fine for this case. ## s/ implementions/implementation # Section 8.3.1: Same comments as Section 8.2.1 # Section 11: IANA actions Consider adding an IANA instruction to update this entry to point to the RFC number to be assigned to this document: CURRENT: FF02:0:0:0:0:0:0:16 All MLDv2-capable routers [RFC3810] # References ## [I-D.ietf-pim-3228bis] should be listed as normative. # Appendix B.2: The document is still about MLD2 OLD: B.2. MLDv2 NEW: B.2. Changes since RFC 3810 # Misc. ## Consider adding captions to all tables (and figures) ## Consider using the same formatting for all tables. For example: The following table describes the changes in multicast address state and the action(s) taken when receiving either Filter Mode Change or Source List Change Records. This table also describes the queries which are sent by the Querier when a particular report is received. Or The following table describes the timer actions when sending or receiving a Multicast Address Specific or Multicast Address and Source Specific Query with the Suppress Router-Side Processing flag not set. Query Action ----- ------ Q(MA,A) Source Timers for sources in A are lowered to LLQT Q(MA) Filter Timer is lowered to LLQT Don’t use the same table format as the other tables. ## Explicit citation of the tables in the main text: e.g., ### OLD: corresponding Current State Record are determined from the per- interface state and the pending response record, as specified in the following table: NEW: corresponding Current State Record are determined from the per- interface state and the pending response record, as specified in Table 3: ### OLD: The following table summarizes the role of the Filter Timer. Section 7.4 describes the details of setting the Filter Timer per type of Multicast Address Record received. NEW: Table 5 summarizes the role of the Filter Timer. Section 7.4 describes the details of setting the Filter Timer per type of Multicast Address Record received. ### OLD: To summarize, the following table describes the forwarding suggestions made by MLDv2 to the routing protocol for traffic originating from a source destined to a multicast address. NEW: To summarize, Table 6 describes the forwarding suggestions made by MLDv2 to the routing protocol for traffic originating from a source destined to a multicast address. Thank you, Cheers, Med