Thanks for address my discuss!  

Note:  I'm leaving the comments below for historical reasons.  

Thanks to Joe Salowey for their secdir review.  Like Paul Wouters and Joe have stated, it appears that the security considerations doesn't really address this potential issues.

Why not MUST?:  There are a number of SHOULDs where the rationale for why one might not take that action is missing.

Thanks for the work and for quickly addressing my previous blocking DISCUSS ballot:
https://mailarchive.ietf.org/arch/msg/pim/rfedJTMeDBgYd59yBj6b1TYLqaU/

-éric

Thanks for all the info and working through everything!

Thank you Joe Touch for his TSV-ART review, I'd like to pick-up on the issues discussed there, so include them here:

(i) It also appears that the limited number of (host) hardware address filters has been
overlooked; i.e., if a device is capable of filtering only 4 multicast
addresses in hardware, the device would more efficiently support 7 addresses if
at least 3 DID collide, rather than ensuring that none collide.  When no
addresses collide and the number of filters is exceeded, the network interface
is driven into promiscuous mode that requires software filtering – i.e., it
completely undermines the goal of this doc.

(ii) The protocol requirements need some refinement. Resistance to failure is NOT
the same as robustness to a single point of failure; the tag phrase and the
definition need to be adjusted to align. Item 3 is “multicast self-assignment
protocol coexistence”, i.e., this isn’t about interoperation with other
protocols in general. Item 7 (collision detection and resolution) is not a
requirement; it is an approach to satisfying other requirements, such as 1, 2,
and 5. It would help if the tag phrases were similar (they seem to be phrases
defining properties, except for #6, which should be “supports host-level
multiplexing” – check this throughout for all lists).

(iii) The Note needs revision; the collisions arise after *rejoining disconnected
networks caused by* a temporary network partition. I.e., it is the rejoining
that causes the problem, not the partitioning. The second list should describe
goals of a design; it seems odd to include “cross-platform availability”, as
this seems to conflate deployment with OS capabilities; it is difficult to
appreciate what OS properties could ever interfere with these mechanisms. An
example would help as would rephrasing this as “OS independence”.

... Please see additional comments in the review that may also be helpful.

I see new text, and new RFC-2119 usage, based on these I have cleared my DISCUSS position.

Thanks to the authors and the WG for their work on this document.

There is an overarching question at the back of my mind on why the WG wishes to publish this document as an RFC when it has already adopted multiple documents related to solutions that supposedly address this problem space (draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id (in IETF LC), draft-ietf-pim-ipv6-zeroconf-assignment, draft-ietf-pim-gaap (experimental)). Just curious ... perhaps the WG can just decide not to publish this as an RFC and instead continue their work-in-progress solutions while keeping this draft as a guidance?

There is a difference between documenting and publishing as an RFC. I don't see the long term benefit of publication of the document given the state of the solution work. There are plenty of examples where such work is adopted but not published as an RFC. 

Anyway, this was not a technical point and I will leave this to the WG and the responsible AD's call.

Hi Nate, Dino, and Mike, 

Thank you for the discussion and changes.

The changes made since -07 [1] address all the points raised in my previous ballot [2]. 

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07&url2=draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-13&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/pim/yvDAR-jVVIuexooqwS9P8FywSNk/

I agree with Joe's SecDir review that the document is a bit light on the Security Considerations.


   It addresses key challenges, such as link-layer address collisions, hardware limitations,
   multicast snooping inefficiencies, and the need to avoid manual configuration.

I find it does not really "address" it, but merely "state" it.

I wouldn't feel it wrong to leave this document as a draft for other developers to look at while
designing solutions specified in other documents.

Thank you to Joel Halpern for the GENART review, and the revisions to the document by the WG are appreciated.

==[ prior DISCUSS ]==
For the PIM WG chairs and responsible AD: this document appears to describe both current deployment issues (Section 2) and requirement/considerations (Section 3, and 5).  However, these topics do not appear to be in scope of 08-02 (https://datatracker.ietf.org/doc/charter-ietf-pim/08-02/) (or 09, https://datatracker.ietf.org/doc/charter-ietf-pim/09/) of the charter.  The closest related text is “Create multicast protocol design experience documents”.  Perhaps deployment issues could be considered “protocol design experience”, but requirements don’t seem to be fit.

I’ll note that this document was adopted in Sept-2023 when the -08 charter (https://datatracker.ietf.org/doc/charter-ietf-pim/08/) from 2015 scoped the WG.  It also didn’t have producing informational requirements/problem statement documents in scope.  
==[ end ]==

I will leave it to the discretion of the responsible AD as explained in https://mailarchive.ietf.org/arch/msg/pim/_AINlGHUQbXgRACrPdQ69yPinZY/ that "7) Develop multicast group address allocation protocols" of the current charter interprets "protocols" to be not just be "technical protocols" but also supporting documents.  I would recommend that when this 8-year old charter is updated, that this point be made explicit.