[pim] Re: Opsdir last call review of draft-ietf-pim-3376bis-10

[Brian Haberman <[e-mail]>]

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