Re: [pim] John Scudder's No Objection on draft-ietf-pim-rfc8736bis-02: (with COMMENT)

[Alvaro Retana <[e-mail]>]

On May 17, 2023 at 1:18:32 PM, John Scudder wrote:


John:

Hi!  Thanks for the review.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for this document. I have one minor concern I'd like to mention. You
> define 13.0 through 15.15 as type.subtype. I assume that each of the 48
> distinct type.subtype tuples is intended to have the exact same semantics as
> the "legacy" 0-12 type space, that is, each type.subtype is logically
> distinct, they are nothing more and nothing less than an extension mechanism.
> In particular, there is no significance if two different ones match on the
> type value but are different on the subtype value, it's really just an 8 bit
> number whose high-order nibble happens to be d, e, or f.
>
> Probably this is obvious enough as it stands, but it seems like it might help,
> and wouldn't hurt, to state it explicitly.

Sure.  Here's a proposal:

OLD>
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, abbreviated
  as FB below) are to be defined by each extended type.

NEW>
5. PIM Type Space Extension

  This document extends types 13, 14, and 15 such that each becomes 16
  new types, resulting in 48 types available for future PIM extensions.
  This extension 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 the new extended types. The remaining
  four flag bits (bits 0-3, abbreviated as FB below) are to be defined by
  each extended type.

  Each of the new extended types is represented by the eight bits
  resulting from the concatenation of the Type and Subtype fields.  No
  relationship is expected or implied between extended type messages with
  a common Type field.


Does this work for you?  Feel free to suggest changes or alternate text.


Thanks!

Alvaro.