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

# Éric Vyncke, INT AD, comments for draft-ietf-pim-rfc8736bis-03

Thank you for the work put into this document. 

Please find below one COMMENT point (but replies would be appreciated even if only for my own education).

Special thanks to Mike McBride for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. 

I hope that this review helps to improve the document,

Regards,

-éric

## Section 3

Can the new header still be named "common header" when section 5 redefines it ? Nothing critical here, more wordsmithing (and I have no proposals).

Thanks for this document,  I found it clear and an easy read!

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.

# GEN AD review of draft-ietf-pim-rfc8736bis-03

CC @larseggert

Thanks to Mallory Knodel for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/KY_LW1lMtizTA-cTQPh7AMWMxRM).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

I think it's wrong to say "updated" in Section 3, because the format hasn't changed since the document it's replacing.  I would just strike the word "updated".  I have similar thoughts about Section 5, which claims to "extend" something, but as far as I can see, nothing is changing since RFC 8736.