[pim] Re: draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-07 ietf last call Opsdir review

Hi Nate,

Thanks for the update and addressing the points.

Looks good now!

Dhruv

On Sun, Jan 25, 2026 at 6:43 PM Karstens, Nate <[email protected]>
wrote:

> Dhruv,
>
>
>
> Thanks for reviewing the document! We addressed your feedback in
> draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-09. Please see below for
> replies and let us know if you have any additional comments.
>
>
>
> Cheers,
>
>
>
> Nate
>
>
>
> *From:* Dhruv Dhody via Datatracker <[email protected]>
> *Sent:* Wednesday, November 19, 2025 09:53
> *To:* [email protected]
> *Cc:* [email protected];
> [email protected]; [email protected]
> *Subject:* [pim] draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-07 ietf
> last call Opsdir review
>
>
>
> 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
>
> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/__;!!EJc4YC3iFmQ!XptMiivFFcvZaMSV7SaB2bBD0Uo0In7BvGbKlrZJg5G9B2aNYSHhNascPTLJyBKtw_Iq5cNja5qg3HO14A$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/__;!!EJc4YC3iFmQ!XptMiivFFcvZaMSV7SaB2bBD0Uo0In7BvGbKlrZJg5G9B2aNYSHhNascPTLJyBKtw_Iq5cNja5qg3HO14A$>.
>
>
>
> 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?
>
> *[Karstens] I think the original formatting of the table may have led to some confusion. Version 09 changes the table format. Hopefully this better communicates the current situation.*
>
>
>
> ---
>
>
>
> ## 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.
>
> *[Karstens] In most cases the document where the technology is defined and the document that adds the entry to the IANA table is the same. That’s not possible in this case, so the make things clear I mention both for MADCAP: defined in 2730 and allocated by this document.*
>
>
>
> - 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.
>
> *[Karstens] Yes, these allocations are for any allocation protocol: server-based, host-based, etc.*
>
>
>
> ---
>
>
>
> ## 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]
>
>
> ------------------------------
>
> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole
> use of the intended recipient(s) and contain information that may be Garmin
> confidential and/or Garmin legally privileged. If you have received this
> email in error, please notify the sender by reply email and delete the
> message. Any disclosure, copying, distribution or use of this communication
> (including attachments) by someone other than the intended recipient is
> prohibited. Thank you.
>

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