Subject: [pim] review comments on draft-ietf-pim-null-register-packing-06

From: <[email-masked]>
Date: Wed, 9 Dec 2020 17:46:49 +0800 (CST)

Hi authors, 

Thank you for your work on this version! It has made a big improvement. 

There may be some nits still in the draft:

1. In section 9, the third paragraph, a spoof Register/a spoof Register-stop, appear that is is from the RP/appear that it is from the RP.

2. In section 10, This document requires the assignment of "Capability bit" (P-bit), flag bit 7 in the PIM Null-Register message./This document requires the assignment of "Capability bit" (P-bit), flag bit 7 in the PIM Register-Stop message.

And the below is my understanding about some specification in the draft, if there is something wrong, appreciate for correcting me:

1. In case the RP supports the capability, the RP sends "P-bit" in the register-stop message? The description in section 5 is: 

"An RP supporting this specification SHOULD set the P-bit in the corresponding Register-Stop messages."

IMO the SHOULD shoud be changed to MUST. Because if the RP wants to receive packet null-register message, when the DR receives the register-stop message without P-bit, for example in section 7, the DR will downgrade to use regular message defined in RFC7761. 

So if the RP wants the DR to send packed null-register message, it MUST always send the register-stop message with P-bit.

2. If my understanding is right, once the DR receives the register-stop message from the RP, whatever the group/source address included in the message, the DR will send the packed null-register message immediately. It will not send packeted null-register message only for the group/source address shown in the register-stop message with P-bit. Is it right?

3. If the RP will make some local policy for different DR or specific group/source? For example, if the RP only wants to receive packet null-register message from a specific DR, and receive regular null-register message from other DRs? IMO this situation will not affect the function defined in this draft. 

And for the specific group/source, IMO it's not necessary. Because it may let one DR to send packed null-register message for some source/groups, and send regular null-register message for other source/groups. It makes the implementation too complicate. What do you think about it?

Best regards,

Sandy