Re: [pim] Zaheduzzaman Sarker's Discuss on draft-ietf-pim-null-register-packing-14: (with DISCUSS)

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

Hi Zahed,

Thanks for your review!

For 1) The P-bit is now explained as per Alvaro’s suggestion.

For 2) For Rob’s and Lar’s DISCUSS, the concerns have also been addressed:
Please check Section 3 & 4 with regards to the N-bit.
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pim-null-register-packing-15


Thanks,
Ananya
From: Alvaro Retana <[e-mail]>
Date: Wednesday, March 1, 2023 at 4:39 AM
To: The IESG <[e-mail]>, Zaheduzzaman Sarker <[e-mail]>
Cc: [e-mail] <[e-mail]>, Mike McBride <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Zaheduzzaman Sarker's Discuss on draft-ietf-pim-null-register-packing-14: (with DISCUSS)
On February 28, 2023 at 2:54:12 PM, Zaheduzzaman Sarker wrote:

Zahed:

Hi!

Thanks for the review!


> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks for working on this document.
>
> I would like to discuss - what is the "P" bit in section 2 and what is "FB" in
> section 3? without proper description of those fields this specification will
> be confusing to be implemented. May be I have missed something in the
> referenced specifications, in that case I would prefer to have the references
> properly stated here.

The P-bit is first mentioned in the text in §5 as "P-bit (Flag bit
TBD1)".  But the definition of the "Packing Capability bit" didn't
explicitly call the it P-bit, I see the confusion.

Suggestion (for §2)>
OLD>
   Packing Capability bit (Flag Bit TBD1): When set, it indicates the
   ability of the RP to receive PIM Packed Null-Register messages, and
   send PIM Packed Register-Stop messages.

NEW>
   Packing Capability bit (P-bit / Flag Bit TBD1): When set, it
   indicates the ability of the RP to receive PIM Packed Null-Register
   messages, and send PIM Packed Register-Stop messages.



The FB ("flag bits") field is part of the common header -- there's a
reference to rfc8736 right after figures 2 and 3.  For the new message
types this document is requesting, Figure 3/rfc8736 applies:

5.  PIM Type Space Extension

   This document defines types 13, 14, and 15, such that each of these
   types has 16 subtypes, providing a total of 48 subtypes available for
   future PIM extensions.  This is achieved by defining a new Subtype
   field (see Figure 3) using the four most significant flag bits (bits
   4-7).  The notation type.subtype is used to reference these new
   extended types.  The remaining four flag bits (bits 0-3) are reserved
   to be used by each extended type (abbreviated as FB below).

       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


Do you want the authors to add something specific to this document?


Thanks!

Alvaro.