[pim] draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-07 ietf l ast call Opsdir review

Dhruv Dhody via Datatracker <[email protected]> Wed, 19 Nov 2025 07:52:35 -0800
Newsgroups gmane.ietf.pim
Message-ID <176356755555.1247821.14784479496899470477@dt-datatracker-5bd94c585b-wk4l4>
Document: draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id
Title: Updates to Dynamic IPv6 Multicast Address Group IDs
Reviewer: Dhruv Dhody
Review result: Has Issues

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

- Document: draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-07

- Reviewer: Dhruv Dhody

- Review Date: 19 Nov 2025

- Intended Status: Standards Track

---

## Summary

Choose one:

- Has Major Issues: I have significant concerns about this document and
recommend that the OPS ADs discuss these issues further with the authors.

## General Operational Comments Alignment with RFC 5706bis

The document does not have any operational consideration. It is only related to
updating the IANA consideration.

## Major Issues

- Section 2, the draft currently lists the “existing” dynamic multicast
group-ID range as 0x80000000–0xFEFFFFFF. RFC 3307 dynamic range is
0x80000000–0xFFFFFFFF. Please check. - Table 1 would benefit from headings and
a legend. It is unclear what the empty cell indicates. Maybe some description
in text alongside the table would make it clear. - Table 2, where is the Host
allocation?

---

## Minor Issues

- Table 2, the reference should point to the document that specified the
assigned values and not the reference to the document where the technology is
defined.

- In the future, if there is another server allocation protocol beyond MADCAP,
would it need a new Range? Some text would be useful as you are moving from
generic "server allocation" to MADCAP.

---

## Nits

- To improve readability, consider adding "This document describes..." rather
than "Describes ...". - s/Section 4.3 describes/Section 4.3 of [RFC3307]
describes/

---

## Related

- The other documents that reference this I-D do it as an informal reference -
    - draft-ietf-pim-gaap
    - draft-ietf-pim-ipv6-zeroconf-assignment
    - draft-ietf-pim-zeroconf-mcast-addr-alloc-ps

This reference should be normative as this I-D is the one that created the
registry.

Thanks!
Dhruv



_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]