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

["Murray S. Kucherawy" <[e-mail]>]

On Wed, Mar 1, 2023 at 8:26 AM Alvaro Retana <[e-mail]> wrote:

> > 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


Thanks, it wasn't clear to me that these two things are referring to the
same allocation since the first one says "This section allocates" when it's
really the later IANA section that does the allocation.


> 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.
>

I managed to miss this in the abstract; I was looking at the upper left
corner of the front page which doesn't indicate that it updates anything at
all.  We should probably fix that.

*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.
>

Thanks, that should be more than sufficient.

-MSK