[pim] Re: draft-ietf-pim-gaap-18 ietf last call Opsdir revie w

Hi Mike,

Thank you for addressing my comments.

For point #1, the added prerequisite paragraph looks good to me.

For point #2, I realize my original comment may not have been precise enough. My concern is not simply about citing the zeroconf draft— that explains the motivation.

What I would like to suggest in the Operational Considerations section is an explicit statement of deployment boundaries: given that PIM is deployed very broadly, GAAP should clarify that it is intended for specific scenarios (zeroconf, unmanaged environments) and is not a general replacement for existing address allocation mechanisms in traditional managed networks.

Specifically, it would help reader or operators if the document states:

1.       The intended administrative scope and scale (e.g., single subnet vs. multi-domain).

2.       That networks with existing centralized allocation services (static assignment, etc.) do not need deploy GAAP.

This avoids the operational risk of someone turning it on in a large network where centralized address governance is already in place.

Hope this helps to clarify my question.

Thanks,
Bo
From: Mike McBride <[email protected]>
Sent: Thursday, August 13, 2026 9:35 AM
To: Wubo (lana) <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: draft-ietf-pim-gaap-18 ietf last call Opsdir review

Hi Bo Wu,

Thank you for the review, please see below:

On Tue, Aug 4, 2026 at 4:01 AM Bo Wu via Datatracker <[email protected]<mailto:[email protected]>> wrote:
Document: draft-ietf-pim-gaap
Title: Group Address Allocation Protocol (GAAP)
Reviewer: Bo Wu
Review result: Clarification Needed

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-ietf-opsawg-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-gaap-18]

- Reviewer: [Bo Wu]

- Intended Status: [Experimental]

---
Summary:

GAAP defines a lightweight decentralized multicast address allocation
mechanism. As an Experimental protocol, the Operational Considerations section
provides useful high-level guidance, but the dependencies on existing multicast
protocols and the deployment boundaries could be clarified further.

## Minor Issues

1. Deployment prerequisites and network dependencies
GAAP Claim messages are sent to well-known multicast addresses. This requires
the underlying network to support multicast routing/forwarding (e.g., IGMP,
PIM-SM, or PIM-SSM). It is recommended that the Operational Considerations
section explicitly state these prerequisites. Deployment boundaries

For another review we added a paragraph which, given your suggestions, now says:
"GAAP requires the underlying network to support IP multicast group
membership (IGMP/MLD) and ASM-capable multicast routing/forwarding
(e.g., PIM-SM) for delivery of Claim messages. Applications using
GAAP-allocated addresses will typically also rely on ASM delivery
for their own traffic, though an application with a single known
source could in principle use PIM-SSM for its own data plane once
its address has been allocated and claimed via GAAP.  In IPv4 deployments
using PIM-SM, the Rendezvous Point(s) serving the GAAP Group Address
and the GAAP IPv4 allocation range need to be configured to support the full
range described in Section 9, since a GAAP node may allocate any address within it."


2. Additionally, Section 7 could clarify the intended deployment boundary
(administrative domain scope, expected scale in terms of nodes/groups). For
example, is the scenario defined in I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps
the primary intended use case for GAAP? Is GAAP applicable to PIM-SM
deployments, and what is its relationship to the PIM RP?

This should all now be covered. The zeroconf draft is already cited in the Introduction as a possible solution.


---

## Nits

3. Terminology structure in Section 2
The definition of "GAAP Group Address" currently embeds the application
allocation range values (TBD1/10, TBD2/32), which is confusing. It is
recommended to move these to the "Group Address" definition to avoid conflating
the control-plane address with the group allocation pool.

Done.


4. Section 4 Group Name definition
The 255-octet maximum length is only stated in "Multi-record parsing". For
consistency, the "Group Name" definition could include: "The string MUST NOT
exceed 255 octets in length (not including the null terminator)."

Done.


5. Section 5.1 gaap.init()
s/"a application"/"an application"/

Done.

6. Section 6.2
Add a comma after "GAAP node": "When a group address is allocated by a GAAP
node, it will build and send a Claim message."

Done.


7. Section 8 Security Considerations
Expand AEAD on first use: "Authenticated Encryption with Associated Data (AEAD)
construction ..."
Done.

thanks,
mike

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