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
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
