Re: [Gen-art] [IANA #1266260] Last Call: <draft-ietf-pim-null-register-packing-13.txt> (PIM Null-Register packing) to Proposed Standard

["Ananya Gopal (ananygop)" <[e-mail]>]

Hi Everyone,



Thanks Alvaro, David and Behcet for the careful review.
Draft-14 has been posted.

Response to comments:

1)

262        For IPv4 PIM Packed Null-Register messages or PIM Packed Register-

263        Stop messages, the DR may perform Path MTU Discovery, but for IPv6

264        this is mandatory.

Is there a reason to not use Normative language?   IPv4 SHOULD...IPv6 MUST...


For IPv6 PIM Packed Null-Register messages or PIM Packed Register-Stop messages, the DR MUST perform Path MTU Discovery. For IPv4 the DR SHOULD perform Path MTU Discovery.


2)

239        When the DR switches to Data Registers from Null-Registers, it should

240        start a Packed_Register_Probe_Time timer.

[] "it should start a Packed_Register_Probe_Time timer" "should"?  Should this be SHOULD or MUST?  If "SHOULD", when it is ok

to not start the timer?


“When the DR switches to Data Registers from Null-Registers, it MUST start a Packed_Register_Probe_Time timer. “

This is only one of the ways to detect an upgrade/downgrade. We were hoping to leave it up to the implementation, but the timer method would be probably the best.


3) Authors: Also, the headers in Figures 2 and 3 should be updated to the

one in Figure 5/rfc8736:

>> Changed as suggested.


Nits/editorial comments:


Nits:

>From IETF ID nits tool:

** Downref: Normative reference to an Informational RFC: RFC 3446

>>

I had it as an informative reference in Draft#11, but we received a review comment to change it to normative:

https://datatracker.ietf.org/doc/draft-ietf-pim-null-register-packing/11/

The PIM Packed Null-Register format should be enabled only if it is supported by all PIM Anycast RP with MSDP members in the RP set for the RP address.


s/multiple PIM Null-Registers [RFC7761] and Register-Stops [RFC7761]/ multiple PIM Null-Registers and Register-Stops [RFC7761]

Changed as Suggested


...

> Flag Bit 7 in PIM common header is defined as Capability bit but in Figure 1

> and throughout the draft it is marked as P bit not as C bit


That is meant to be the Packed Capability, hence "P".  But you bring

up a good point in that the terminology is not consistent.  The text

should be consistent in using "packet capability" (vs just

"capability").


The draft now explicitly defines the P-bit  as “Packing Capability”.
[EoR]

Thanks,
Ananya

From: Alvaro Retana <[e-mail]>
Date: Wednesday, February 15, 2023 at 11:22 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, Ananya Gopal (ananygop) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Ramakrishnan Chokkanathapuram Sundaram (ramaksun) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [IANA #1266260] Last Call: <draft-ietf-pim-null-register-packing-13.txt> (PIM Null-Register packing) to Proposed Standard
On February 15, 2023 at 12:36:24 PM, David Dong wrote:


David:

Hi!

Your question triggered a quick review:

> IANA Question --> Should the Flag Bits for each of these message types be
> set to: "0-7: Reserved" ?

In short, the answer is:  No, they should be set to "0-3: Reserved".


We're using the extended types defined in rfc8736, so the next
available types are 13.0 and 13.1.

Authors: Also, the headers in Figures 2 and 3 should be updated to the
one in Figure 5/rfc8736:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |Subtype|  FB   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 3: Subtypes


Sorry for missing this before.

Thanks!

Alvaro.