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

[Alvaro Retana <[e-mail]>]

On March 1, 2023 at 3:17:51 AM, Murray Kucherawy wrote:


Murray:

Hi!

Thanks for the review!


> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Feel free to set me straight here if I'm wrong, but:
>
> Section 2 says: "This section allocates a bit ..."
>
> Doesn't this mean either (a) there should be a registry for these bits, and if
> there is, there should be one or more corresponding IANA actions; or (b) this
> document should update RFC 7761 so that the allocation of a previously
> reserved bit is discoverable somehow?

There is a registry [1] and a corresponding action:

   When this document is published, IANA is asked to assign a Packing
   Capability bit (TBD1) in the PIM Register-Stop Common Header from
   the PIM Message Types registry.

[1] https://www.iana.org/assignments/pim-parameters/pim-parameters.xhtml#message-types


However, as you can see from the registry, the bits are still marked
as Reserved.  We noticed this issue several days ago :-( -- long story
short:

rfc8736 (PIM Message Type Space Extension and Reserved Bits) updated
rfc7761 (and others) with the intent of reallocating the reserved bits
-- from the Abstract:

   The PIM version 2 messages share a common message header format.  The
   common header definition contains eight reserved bits.  This document
   specifies how these bits may be used by individual message types and
   creates a registry containing the per-message-type usage.  This
   document also extends the PIM type space by defining three new
   message types.  For each of the new types, four of the previously
   reserved bits are used to form an extended type range.

   This document updates RFCs 7761 and 3973 by defining the use of the
   currently Reserved field in the PIM common header.  This document
   further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754,
   and 8364, by specifying the use of the currently reserved bits for
   each PIM message.


*But* we focused too much on the type extension, getting ready for the
work in this draft, and we overlooked the change from Reserved to
Unassigned.  It is specially embarrassing because I am one of the
authors of rfc8736. :-(

After talking to Stig, my co-author, we think that the change in
status (from Reserved to Unassigned) is too much for an errata report,
so we wrote rfc8736bis [2], where that is the only significant change.

[2] https://datatracker.ietf.org/doc/html/draft-venaas-pim-rfc8736bis-00


We'll have the references in this document point to rfc8736bis and ask
the WG/AD for "expedited processing” to delay publication as little as
possible.


Alvaro.