PIM Message Type Space Extension and Reserved Bits
draft-ietf-pim-reserved-bits-04

I support Barry Leiba’s DISCUSS position on clarifying the structure of the IANA table.  I would add that the convention of using the decimal point to convey a sub-type number should be explained (i.e., 13.4 is type=13, sub-type=4)

Editorial Nits:
-- Per Page Title.  Typo.  s/Type Extention/Extension/

-- Section 3. Typo.  s/FIgure 1/Figure 1/

-- Section 4.2.  Unlike Section 4.1 and 4.3, this section doesn’t say “The usage of the bit is defined in that document”.  

-- Section 5.  Capitalize. s/pim extension/PIM extensions/

Thank you for the work put into this document. 

Regards,

-éric

== COMMENTS ==

-- Section 3 --
C.1) Is it "Flags Bits" (two "s") as in figure 1 or "Flag bits" (one "s") as in the text ?

C.2) Shouldn't PIM Ver and Checksum fields be described?


-- Section 4.2 --
C.2) I am a tad inconfortable to have "bits" of a field named "flag bits" to be used for sub-type. For me, "bits" are completely unstructured and atomic and using 4 of those bits to build a 4-bit field does not seem natural. Rather than naming the field "flags bits" what about "special purpose bits" or something similar ?

Barry caught *literally* every last comment I had, so I have nothing to add. I support his DISCUSS on the readability of the IANA table.

I'm guessing this is unnecessary but just wanted to check: do you need a further extension point in case all 48 subtypes of types 13, 14, and 15 get used up at some point? That is, RFC 6166 had reserved a code point for future extensions of the type space. Is it possible that another future extension will be needed and if so, should a code point be reserved for it?

(Thanks for addressing my DISCUSS about the registry format!)

And just a few minor editorial comments:

— Abstract —

   specifies how these bits may be used by individual message types, and
   creates a registry containing the per message type usage.

There needs to be hyphens in “per-message-type”, as it’s a compound modifier (and similarly in the second paragraph of the Introduction (but not in the first paragraph, where it isn’t a modifier)).

— Section 3 —

       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  |   Flags Bits  |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        FIgure 1: New Common Header

   The Flags Bits field is defined in Section 4.  All other fields
   remain unchanged.

The rest of the document calls these “Flag Bits”, without the “s” on “Flags”.  Can we change these two instances to be consistent with that?

— Section 4 —

   The specification of a new PIM
   type, MUST indicate whether the bits should be treated differently.

Remove the comma, please.

   When defining Flag Bits it is helpful to have a well defined way of
   referring to a particular bit.

Hyphenate “well-defined”.

Thanks for this; after the table edits under discussion, it will be a very useful document.

I just have a few minor comments.

It is perhaps slightly unusual to have an Updates: relationship but only
an informative reference relationship to the documents being updated,
but in this case it seems appropriate.

Section 1

   type usage.  Documents defining a new message type MUST define the
   usage of the corresponding Flag Bits.

Is "leave some of them Reserved for Future Use" an acceptable
definition?  (Section 4 implies "yes".)  Pedagogically, it seems
redundant to say "MUST define" and also have text in Section 4 that
gives a default behavior if the "MUST define" is ignored.

Section 3

It looks like 7761 specifies that the flag bits are included in the
Checksum (in the common header); we may want to call that out in case
some implementation had been short-circuiting the actual flags value for
checksum verification.

Section 5

   to be used by each extended type.  Documents defining a new extended
   message type MUST define the usage of the corresponding Flag Bits.

(Same comment as for Section 1.)

Hi,
I support Barry's DISCUSS on the IANA table and his proposal looks great.
However I wonder if the new entries shouldn't be
   ---------------------------------------------------------------------
    13.0-13.15            Unassigned                  [this document]
                       0-3      (Reserved)                    [this document]
    14.0-14.15            Unassigned                  [this document]
                       0-3      (Reserved)                    [this document]
    15.0-15.15            Unassigned                  [this document]
                       0-3      (Reserved)                    [this document]
   ---------------------------------------------------------------------

nit in the intro:
"these documents"
It is not fully clear to which docs you refer to. I guess it's all the ones being updated, but still.