Hi Jouni!
Thanks for the comments. Responses inline...
On 6/4/24 5:20 PM, Jouni Korhonen via Datatracker wrote:
Reviewer: Jouni Korhonen Review result: Has Nits 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
Will fix.
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.
RFC 4604 says:"The rationale is that EXCLUDE mode does not apply to SSM addresses, and an SSM-aware router will ignore MODE_IS_EXCLUDE and CHANGE_TO_EXCLUDE_MODE requests in the SSM range."
The use of SHOULD NOT in this case provides implementers flexibility given that routers will ignore such messages.
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.
Failure to ignore the EXCLUDE message for addresses in the SSM range will not break anything. It may lead to extraneous traffic, but that is self-correcting given the soft state nature of multicast.
If there is no cases to describe for 1) and 2) the I would use MUST NOT and MUST accordingly..
Given that this draft is meant to correct errata so that the standard can advance to Internet Standard, we can't simply change the normative guidance in the protocol at this point.
Regards, Brian
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
