Updates to Dynamic IPv6 Multicast Address Group IDs
draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-13

Thanks to Russ Housley for their secdir review

General:  spell out acronyms on first use.  MADCAP is one example.

Thanks for the work in this document. 

I STRONGLY really regret that this I-D was not in int-area and that the WGLC/CfA were not forwarded to int-area (AFAIK). In my opinion, it *does not fit* the PIM WG charter as it is not about protocol specifications.

But, the most important thing is the content and not the 'wrong' process.

Thanks also to Daniel Migault for his INT directorate review: https://datatracker.ietf.org/doc/review-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-10-intdir-telechat-migault-2026-02-19/ and I have to read the authors' response.

Some non-blocking comments:

# Abstract

In a PS, s/the document also suggests/the document also defines/

Also be explicit on how the I-D updates RFC 3307.

# Section 2

s/for destination address G/for destination *group* address G/ ?

# Section 3

Please expand MADCAP.

# Section 5

Please use the (new) correct name rather than ""IPv6 Multicast Address Space Registry", also add a reference URI.

# Section 6

`National Marine Electronics Association` from which country ?

I note the Shepherd writeup says "Majority of the working group is silent, but believe most of the WG silently support it. No one is against." - This seems a very weak position for a PS, and perhaps reflects a lack of review - see Eric's comment on INTAREA.

Abstract
The wording used in the abstract seems to speculate about possible recommendations, and would be better written with terms that "define" and "specify":
/It recommends replacing these allocations with a new registry/ - could this be: /recommends/replaces/?
/The document also suggests initial contents of the new registry:/ - could this be: /suggests/defines/?

The GENART review notes several concerns around the details of the requested allocations. Please check carefully and ammend these.

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

I have a few minor comments that should be fixed before publication.

1) No BCP14 keywords seem to be used in the document. Please remove that template and those references.

2) RFC2908 has been obsoleted by RFC6308

3) Section 1:
s/IPv multicast address/IP multicast address

"Abstract", paragraph 0
>    This document describes limitations of the existing range of dynamic
>    IPv6 multicast addresses specified in RFC3307.  It recommends
>    replacing these allocations with a new IANA registry in the IPv6
>    Multicast Address Space registry group.  The document also defines
>    initial contents of the new registry: a reduced allocation for MADCAP
>    (RFC2730), a range for SSM, a Private Use range, a range for
>    Experimental Use, and Solicited-Node multicast addresses (which were
>    not previously noted in RFC3307, Allocation Guidelines for IPv6
>    Multicast Addresses).

Generally, the Abstract clearly states if the document is updating or obsoleting another document. This one mentions the document, but not that it is being updated. It is only later in the Introduction that you learn that RFC3307 is being updated.

I also agree with Gorry that for a PS document, the use of words such as "recommends" is a poor choice. 

Section 1, paragraph 2
>    Only one server allocation protocol has been defined at the time of
>    writing (see [RFC2730]), but
>    [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] advocates developing a
>    decentralized, zero-configuration host allocation protocol.  This
>    document updates Section 4.3 of [RFC3307] to allow multiple dynamic
>    allocation protocols to coexist on the same network, and so that
>    dynamic IPv6 multicast group ID ranges better align with current
>    practices for protocol number assignment.

I find the last sentence of the paragraph to be confusing. Which "current practices" are being referred to? Can the sentence be simplified to say something like:
"... on the same network, and to enable that the dynamic IPv6 multicast group IP ranges suggested in this document should be followed."

Section 2, paragraph 2
>    However, SSM is not universally supported (see [RFC4607], Section 6
>    and [RFC8815], Section 3.1).  This document defines a range of
>    dynamic IPv6 multicast group IDs for use in environments that do
>    support SSM.

This section seems to be justifying why a range of addresses should be assigned for SSM, till it does not, based on the first sentence of the above paragraph. If SSM is not widely deployed, why not return the range to unassinged pool and maybe later, when the SSM usage picks up, a range could be allocated for it.

Section 4, paragraph 0
>    This document reduces the range of group ID values available for
>    MADCAP ([RFC2730]).  At the time of writing, there is only one known
>    implementation of MADCAP, and there are no known large-scale
>    deployments.  Any implementations of MADCAP (known or otherwise)
>    should be updated to reflect the new group ID range set forth in
>    Table 2.  Any existing deployments of MADCAP should either use an
>    updated implementation or operate in an environment without other
>    IPv6 multicast address allocation protocols.

I will note that the Shepherd report, on the question of any existing implementation says "Nothing to implement here". While I agree that it is not protocol implementation in a traditional sense of the word, nevertheless, this document does make a note of how existing implementations could be affected by the new allocation scheme. The Shepherd report should be updated to reflect that.

This document does not use RFC2119 keywords, but contains the RFC8174
boilerplate.

The IANA review of this document seems to not have concluded yet.

No reference entries found for these items, which were mentioned in the text:
[avoiding].

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 2
>    This document adheres to the IPv multicast address architecture
>    outlined in [RFC4291], [RFC3307], [RFC7371], et al.

What is "IPv"?

Reference [RFC2908] to RFC2908, which was obsoleted by RFC6308 (this may be on
purpose).

Document references draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-11, but -13 is
the latest available revision.

Found non-HTTP URLs in the document:

 * lispers.net

These URLs in the document did not return content:

 * lispers.net

Hi Nate, Dino, and Mike,

Thank you for the discussion and for the changes.

The changes made in [1] addresses all the comments in my previous ballot [2]. Much appreciated.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-10&url2=draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-12&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/pim/jJhkEw4kOdazy1-p7_Ou5a2JD-I/

Thank you to Sue Hares for the GENART review.

** idnits reports:
  -- The draft header indicates that this document updates RFC3307, but the
     abstract doesn't seem to directly say this.  

[Roman] Please explicitly state that this document updates RFC3307.

  == The document doesn't use any RFC 2119 keywords, yet seems to have RFC
     2119 boilerplate text.

[Roman] Remove the boilerplate text.

** Abstract.  Editorial.
   It recommends
   replacing these allocations with a new IANA registry in the IPv6
   Multicast Address Space registry group. 

What does it mean to have a recommendation to replace allocations? Doesn’t it define a new allocation?  The current text reads like a suggestion is being made.

** Section 3.  Consider citing Section 4.1 and 4.2 of RFC8126 to explain the “Private Use” and “Experimental” ranges.

# Internet AD comments for draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-12
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/

## Comments

* Find the referencing of RFC 4291 to be confusing, as I can't see how this
  document connect the group ID to the 4291 prefix ff02::1:<group_id> for
  this purpose.