Last Call Review of draft-ietf-pim-3376bis-10
review-ietf-pim-3376bis-10-opsdir-lc-korhonen-2024-06-04-00
Request | Review of | draft-ietf-pim-3376bis-10 |
---|---|---|
Requested revision | 10 (document currently at 12) | |
Type | IETF Last Call Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2024-06-05 | |
Requested | 2024-05-21 | |
Requested by | Gunter Van de Velde | |
Authors | Brian Haberman | |
I-D last updated | 2025-03-28 (Latest revision 2024-08-27) | |
Completed reviews |
Rtgdir IETF Last Call review of -10
by Adrian Farrel
(diff)
Opsdir IETF Last Call review of -10 by Jouni Korhonen (diff) Genart IETF Last Call review of -10 by Stewart Bryant (diff) Secdir IETF Last Call review of -10 by Loganaden Velvindron (diff) Intdir Telechat review of -11 by Bob Halley (diff) |
|
Assignment | Reviewer | Jouni Korhonen |
State | Completed | |
Request | IETF Last Call review on draft-ietf-pim-3376bis by Ops Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/ops-dir/HSk6aWggt4o1I7PIB3zVPZ-dJ9g | |
Reviewed revision | 10 (document currently at 12) | |
Result | Has nits | |
Completed | 2024-06-04 |
review-ietf-pim-3376bis-10-opsdir-lc-korhonen-2024-06-04-00
I am an assigned OPS-DIR directorate reviewer for draft-ietf-pim-3376bis-10. Summary: Ready with nits Overall I found the document ready for publication. Editorial nits: 1) There are ~8 occasions where "section Section x.y.z" is used. Remove the extra section word. - line 530 s/Section Section 4.1.9/Section 4.1.9 - line 555 s/section Section 8.1/Section 8.1 - line 739 s/section Section 4.2.13/Section 4.2.13 - line 979 s/Section Section 3.2/Section 3.2 - line 1241 s/section Section 7/Section 7 - line 1359 s/Section Section 6.4/Section 6.4 - line 1583 s/Section Section 6.6.3/Section 6.6.3 - line 1674 s/section Section 7/Section 7 Questions: 1) For example in Section 4.2.13 it states: "An SSM-aware host SHOULD NOT send a MODE_IS_EXCLUDE record type for multicast addresses that fall within the SSM address range." Since this is not "MUST NOT send" what is the occasion when the host chooses not to "SHOULD NOT" and sends a MODE_IS_EXCLUDE record type for multicast addresses that fall within the SSM address range? The case justifying going against "SHOULD NOT" is not described anywhere or I just did not find/understand it. 2) Similarly to 1) in Section 6.4 what is the case when the router would not "SHOULD ignore"? The case is not described anywhere or I did not find/understand it. If there is no cases to describe for 1) and 2) the I would use MUST NOT and MUST accordingly..