PIM Message Type Space Extension and Reserved Bits
RFC 8736
Yes
No Objection
Recuse
Note: This ballot was opened for revision 03 and is now closed.
Roman Danyliw No Objection
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/
Éric Vyncke No Objection
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 ?
Alvaro Retana Recuse
(Deborah Brungard; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
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.
(Alexey Melnikov; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
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?
(Barry Leiba; former steering group member) (was Discuss) No Objection
(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”.
(Benjamin Kaduk; former steering group member) No Objection
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.)
(Ignas Bagdonas; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
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.
(Mirja Kühlewind; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection