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

Hi Bo,

ok sounds good, thanks. We will add a paragraph in the next update to
include your suggested text.

mike

On Wed, Aug 12, 2026 at 9:20 PM Wubo (lana) <[email protected]> wrote:

> 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]>
> 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]