Internet Group Management Protocol, Version 3
draft-ietf-pim-3376bis-12

Thanks to Loganaden Velvindron for the secdir review

Security Considerations:  Both integrity (forgery) and authentication is addressed sufficiently.  Consider adding a sentence to address the lack of confidentiality (and privacy) protection. For example, exposure may lead to a passive listener being able to map the network.

It is understood that it is very difficult/impossible to provide either confidentiality protection for traffic in these protocols.

# Internet AD comments for draft-ietf-pim-3376bis-11
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S9.4

* "IPsec", per RFC 4301 S1.1.  =)

I reviewed the diff between this and RFC3376 only for this position.

I don't understand the SHOULD NOTs in Section 4.2.13.  What harm to interoperability results from sending them if they are simply ignored?

Thank you to Stewart Bryant for the GENART review.

** Consider explicitly naming the registries in question:

-- Section 4., “IGMP message types are registered per [I-D.ietf-pim-3228bis].”
-- Section 4.1.4.  Flags, “The Flags field is a bitstring managed by an IANA registry defined in [I-D.ietf-pim-3228bis].”
-- Section 4.2.3.  Flags, “The Flags field is a bitstring managed by an IANA registry defined in [I-D.ietf-pim-3228bis].”

** Section 10
   All IGMP types described in this document are managed via
   [I-D.ietf-pim-3228bis].

Does this imply that there is no IANA action in this document?  Consider just saying that.

** Idnits reported the following:

  -- The document seems to contain a disclaimer for pre-RFC5378 work, and may
     have content which was first submitted before 10 November 2008.  The
     disclaimer is necessary when there are original authors that you have
     been unable to contact, or if some do not wish to grant the BCP78 rights
     to the IETF Trust.  If you are able to get all authors (current and
     original) to grant those rights, you can and should remove the
     disclaimer; otherwise, the disclaimer is needed and you can ignore this
     comment. (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

Has one of the original authors of RFC3376 been approached to file the appropriate paperwork with the Trust to assign the new rights?

Thank you for writing this document. Also, thank you to Jouni Korhonen for the OpsDir review -- https://datatracker.ietf.org/doc/review-ietf-pim-3376bis-10-opsdir-lc-korhonen-2024-06-04/
I had similar questions (well, ok, I didn't until I read Jouni's review, and then I did :-)) -- thanks to Brian for answering them, his reply makes sense to me.

Thanks for working on this specification.

# Éric Vyncke, INT AD, comments for draft-ietf-pim-3376bis-11

Thank you for the work put into this document. I have mainly reviewed the diff with RFC 3376:
https://author-tools.ietf.org/iddiff?url1=rfc3376&url2=draft-ietf-pim-3376bis-11&difftype=--html

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit.

Special thanks to Stig Venaas for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status.

Other thanks to Bob Halley, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-pim-3376bis-11-intdir-telechat-halley-2024-07-28/ (just one nit that I have repeated in my ballot)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Internet Standard ?

Should this document aims at "Internet standard" per RFC 6410 ?

## Sections 4.1.4 and 4.2.3

Should the IANA registry name be used rather than the reference to the RFC creating that registry ?

Should there be the usual text "unassigned bits in the Flags field MUST be set to 0 on transmission and MUST be ignored on reception" ?

## Section 4.2.13

Perhaps a little pedantic, but what is a "valid IP address" ? Suggest using "valid unicast IP address" (and perhaps "non link-local" ?).

# NITS (non-blocking / cosmetic)

## Section 6.4.2

From Bob Halley's review `6.4.2 paragraph 8 duplicates a word in the text "Section Section 6.6.3".`