Skip to main content

Telechat Review of draft-ietf-pim-igmp-mld-extension-05
review-ietf-pim-igmp-mld-extension-05-intdir-telechat-pauly-2022-01-20-00

Request Review of draft-ietf-pim-igmp-mld-extension
Requested revision No specific revision (document currently at 08)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2022-01-30
Requested 2022-01-19
Requested by Éric Vyncke
Authors Mahesh Sivakumar , Stig Venaas , Zheng Zhang , Hitoshi Asaeda
I-D last updated 2022-01-20
Completed reviews Rtgdir Last Call review of -05 by Ron Bonica (diff)
Genart Last Call review of -05 by Pete Resnick (diff)
Tsvart Last Call review of -05 by Wesley Eddy (diff)
Intdir Telechat review of -05 by Tommy Pauly (diff)
Assignment Reviewer Tommy Pauly
State Completed
Request Telechat review on draft-ietf-pim-igmp-mld-extension by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/0rxwTcue4xXTEwiaQ0rmtgO1B50
Reviewed revision 05 (document currently at 08)
Result Ready w/issues
Completed 2022-01-20
review-ietf-pim-igmp-mld-extension-05-intdir-telechat-pauly-2022-01-20-00
Thanks for writing this concise and clear document. The addition of TLV
extensions seems useful.

I don't see any major issues, but there are a few minor ones.

Like the genart reviewer, I believe this "should" ought to be normative:

"When this extension mechanism is used, the number of Group Records in each
Report message should be kept small enough that the entire message, including
any extension TLVs can fit within the network MTU."

In Section 4, I suggest rewording this and fixing capitalization:

"To check this, one will need to walk through each of The TLVs until there are
less than four octets left in the IP payload."

to:

"To check this, the parser needs to walk through each of the TLVs until there
are less than four octets left in the IP payload."

In Section 5, I suggest rewording this:

"IGMP and MLD implementations, host implementations in particular, rarely
change, and it is expected to take a long time for them to support this
extension mechanism."

to:

"IGMP and MLD implementations (particularly implementations on hosts) rarely
change, and the adoption process of this extension mechanism is expected to be
slow."

I also suggest that you consider giving guidance for preventing this new
extension point from ossifying, given the slow rate of change. Please see the
discussion in RFC 9170. For example, if you cannot guarantee active use and
change, you may want to suggest synthetic use of the extension point
("greasing" by endpoints sending unknown type values every now and then to make
sure receivers correctly handle unknown types).