Early Review of draft-ietf-pim-rfc1112bis-07
review-ietf-pim-rfc1112bis-07-iotdir-early-nordmark-2026-01-27-00
| Request | Review of | draft-ietf-pim-rfc1112bis |
|---|---|---|
| Requested revision | No specific revision (document currently at 08) | |
| Type | Early Review | |
| Team | Internet of Things Directorate (iotdir) | |
| Deadline | 2026-02-04 | |
| Requested | 2026-01-20 | |
| Requested by | Stig Venaas | |
| Authors | Toerless Eckert , Dr. Steve E. Deering | |
| I-D last updated | 2026-02-26 (Latest revision 2026-02-26) | |
| Completed reviews |
Rtgdir Early review of -07
by Zheng Zhang
(diff)
Intdir Early review of -07 by Pascal Thubert (diff) Iotdir Early review of -07 by Erik Nordmark (diff) Secdir Early review of -07 by Brian Weis (diff) |
|
| Comments |
If possible, it would be good to get some of these reviewers. SECDIR: Brian Weis, Kyle Rose, Dave Thaler TSVDIR: Michael Tüxen, Kyle Rose INTDIR: Jen Linkova, Rick Taylor, Pascal Thubert, Michael Tüxen, Dave Thaler IOTDIR: Pascal Thubert, Eric Nordmark, Carsten Borman Note that Brian Haberman has done extensive reviews of this document, so it is best to not have him as a reviewer. |
|
| Assignment | Reviewer | Erik Nordmark |
| State | Completed | |
| Request | Early review on draft-ietf-pim-rfc1112bis by Internet of Things Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/iot-directorate/_0-OQaHy02U84BNoVD0UL7as0x8 | |
| Reviewed revision | 07 (document currently at 08) | |
| Result | Ready w/issues | |
| Completed | 2026-01-27 |
review-ietf-pim-rfc1112bis-07-iotdir-early-nordmark-2026-01-27-00
I have a question around Level 2L, which is new to me. In the past there has been an assumption that layer 2 devices (bridges, L2 switches) can perform IGMP/MLD snooping to determine what to filter based on Ethernet multicast addresses. Back in the day this possible except that the all-hosts (IPv4) and all-nodes (IPv6) would always need to be forwarded at L2. Has the industry moved away from IGMP/MLD snooping? And is the draft trying to say that an implementation is free to implement support for IGMP/MLD snooping but it is not part of the standard? (The intent of the different sections are not quite clear to me on this topic.) Security considerations: have there been any discussion about the fact that applications should not assume that traffic sent to a link-local multicast address was sent by a host on the attached link? (various tunneling approaches can be used to have a router potentially send such a packet on a link.) Is this worth noting? Terminology nit: For better or worse, the IPv6 RFCs do not use the term "IPv6 host group", yet in this document that term appears three times. Some of those are odd - "IPv6 host group address" should be replaced by "IPv6 multicast address". The one in section 4 might make sense to keep (but reword) to make the connection with the IPv4 terminology. Thus I'd suggest changing "IPv6 Host groups are identified by IPv6 addresses" to "In IPv6 the concept of host groups are identified by IPv6 multicast addresses" or something along those lines. Section 9.2: I'm having a hard time parsing this sentence "do or may include backward compatibility with IGMPv1" since it isn't clear what "do or may" means when referring to existing specifications. Is this intended to refer to implementations? Section 10.8 typo: "MLS" should be "MLD". Section 12.2 says "keep an IP multicast address secret" That can easily be read as "secure" when "obscure" would be a better name for it. This is an observation about the pssibility to have randomly generated IPv6 multicast addresses, and if such are used, it is hard (but not impossible) to find them by trial and error. But many IPv6 protocols use well-defined fixed multicast addresses.