[pim] Re: Last Call: <draft-ietf-pim-gaap-18.txt> (Group Address Allocation Protocol (GAAP)) to Experimental RFC

[Mike McBride <[e-mail]>]

Hi Nico,

On that last question regarding encryption, how about we add this one
sentence as you suggested: "Encryption SHOULD only be enabled within a
coordinated administrative domain where all GAAP nodes share the same
encryption configuration and key."? Thank you for the review.

mike

On Fri, Jul 17, 2026 at 9:53 PM Dino Farinacci <[e-mail]> wrote:

> Some quick replies.
>
> > On Jul 17, 2026, at 9:20 AM, Nico Cvitak <[e-mail]> wrote:
> >
> > Hi,
> >
> > I think this draft is a great step forward for multicast address
> allocation, but I have some comments regarding section 8.
>
> Thanks.
>
> > How are collisions meant to be resolved across GAAP nodes with different
> encryption configurations, or lack
>
> These would be different domains that don't connect to each other. You can
> run separate instances, especially when there are multicast group
> boundaries so the well-known groups stay disjoint.
>
> > thereof? It sounds like they'd just be allowed to collide given the text
> in section 8, which doesn’t seem ideal?
>
> If there are no group boundaries, then the packets go to all members of
> the well-known group but are dropped by the ones without common encryption
> keys.
>
> > I'd imagine that applications wanting to use GAAP as a zero
> configuration multicast address allocation protocol as highlighted in
> [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] would just not use encryption
> for "zero configuration”?
>
> Right, a tradeoff between plug-and-play and secure communication.
>
> > Perhaps section 8 should be amended to only suggest encryption when
> deployed in a coordinated administrative domain where all GAAP nodes share
> the same encryption configuration?
>
> I thought we had something like that. I'll leave this for Mike and Stig to
> comment about.
>
> Dino
>
> >
> > Thanks,
> > Nico
> >
> >> On Jul 13, 2026, at 11:54 AM, The IESG <[e-mail]> wrote:
> >>
> >>
> >> The IESG has received a request from the Protocols for IP Multicast WG
> (pim)
> >> to consider the following document: - 'Group Address Allocation Protocol
> >> (GAAP)'
> >>  <draft-ietf-pim-gaap-18.txt> as Experimental RFC
> >>
> >> The IESG plans to make a decision in the next few weeks, and solicits
> final
> >> comments on this action. Please send substantive comments to the
> >> [e-mail] mailing lists by 2026-08-03. Exceptionally,
> comments may
> >> be sent to [e-mail] instead. In either case, please retain the
> beginning
> >> of the Subject line to allow automated sorting.
> >>
> >> Abstract
> >>
> >>
> >>   This document describes a design for a lightweight decentralized
> >>   multicast group address allocation protocol (named GAAP and
> >>   pronounced "gap" as in "mind the gap").  The base allocation protocol
> >>   requires no centralized service and minimal configuration, although
> >>   deployments using encryption or administrative scoping may require
> >>   configuration.  The protocol runs among group participants which need
> >>   a unique group address to send and receive multicast packets.
> >>   Tailored for IPv4 and IPv6 networks, this design offers a simple,
> >>   lightweight option rather than extending an existing protocol.
> >>
> >>
> >>
> >>
> >> The file can be obtained via
> >> https://datatracker.ietf.org/doc/draft-ietf-pim-gaap/
> >>
> >>
> >>
> >> No IPR declarations have been submitted directly on this I-D.
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> pim mailing list -- [e-mail]
> >> To unsubscribe send an email to [e-mail]
> >
>
>