[RTG-DIR]Rtgdir last call review of draft-ietf-pim-3810bis-10

[Mohamed Boucadair via Datatracker <[e-mail]>]

Reviewer: Mohamed Boucadair
Review result: Has Issues

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