[pim] Re: Last Call: <draft-ietf-pim-gaap-18.txt> (Group Address Allocation Protocol (GAAP)) to Experimenta l RFC
Nico Cvitak <[email protected]> Fri, 17 Jul 2026 12:20:58 -0400
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <[email protected]> |
--===============3539474158999219087== Content-type: multipart/alternative; boundary="Apple-Mail=_252EB217-95FF-4807-9CD4-6EA8B7819BF4" --Apple-Mail=_252EB217-95FF-4807-9CD4-6EA8B7819BF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I think this draft is a great step forward for multicast address = allocation, but I have some comments regarding section 8. How are collisions meant to be resolved across GAAP nodes with different = encryption configurations, or lack thereof? It sounds like they'd just = be allowed to collide given the text in section 8, which doesn=E2=80=99t = seem ideal? 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 = <https://datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc= -ps/>] would just not use encryption for "zero configuration=E2=80=9D? 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? Thanks, Nico > On Jul 13, 2026, at 11:54=E2=80=AFAM, The IESG = <[email protected]> wrote: >=20 >=20 > 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 >=20 > 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 > [email protected] mailing lists by 2026-08-03. Exceptionally, = comments may > be sent to [email protected] instead. In either case, please retain the = beginning > of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > 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. >=20 >=20 >=20 >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-pim-gaap/ >=20 >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > pim mailing list -- [email protected] > To unsubscribe send an email to [email protected] --Apple-Mail=_252EB217-95FF-4807-9CD4-6EA8B7819BF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8"></head><body = style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; = line-break: after-white-space;"><div>Hi,</div><div><br></div><div>I = think this draft is a great step forward for multicast address = allocation, but I have some comments regarding section = 8.</div><div><br></div><div>How are collisions meant to be resolved = across GAAP nodes with different encryption configurations, or lack = thereof? It sounds like they'd just be allowed to collide given the text = in section 8, which doesn=E2=80=99t seem = ideal?</div><div><br></div><div>I'd imagine that applications wanting to = use GAAP as a zero configuration multicast address allocation protocol = as highlighted in [<a = href=3D"https://datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-add= r-alloc-ps/">I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps</a>] would just = not use encryption for "zero = configuration=E2=80=9D?</div><div><br></div><div>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?</div><div><br></div><div>Thanks,</div><div>Nico</div><div><= br><blockquote type=3D"cite"><div>On Jul 13, 2026, at 11:54=E2=80=AFAM, = The IESG <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><div><br>The IESG has received = a request from the Protocols for IP Multicast WG (pim)<br>to consider = the following document: - 'Group Address Allocation = Protocol<br>(GAAP)'<br> <draft-ietf-pim-gaap-18.txt> as = Experimental RFC<br><br>The IESG plans to make a decision in the next = few weeks, and solicits final<br>comments on this action. Please send = substantive comments to the<br>[email protected] mailing lists by = 2026-08-03. Exceptionally, comments may<br>be sent to [email protected] = instead. In either case, please retain the beginning<br>of the Subject = line to allow automated sorting.<br><br>Abstract<br><br><br> = This document describes a design for a lightweight = decentralized<br> multicast group address allocation = protocol (named GAAP and<br> pronounced "gap" as in "mind = the gap"). The base allocation protocol<br> requires = no centralized service and minimal configuration, although<br> = deployments using encryption or administrative scoping may = require<br> configuration. The protocol runs among = group participants which need<br> a unique group address to = send and receive multicast packets.<br> Tailored for IPv4 = and IPv6 networks, this design offers a simple,<br> = lightweight option rather than extending an existing = protocol.<br><br><br><br><br>The file can be obtained = via<br>https://datatracker.ietf.org/doc/draft-ietf-pim-gaap/<br><br><br><b= r>No IPR declarations have been submitted directly on this = I-D.<br><br><br><br><br><br>______________________________________________= _<br>pim mailing list -- [email protected]<br>To unsubscribe send an email to = [email protected]<br></div></div></blockquote></div><br></body></html>= --Apple-Mail=_252EB217-95FF-4807-9CD4-6EA8B7819BF4-- --===============3539474158999219087== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGltIG1haWxp bmcgbGlzdCAtLSBwaW1AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byBw aW0tbGVhdmVAaWV0Zi5vcmcK --===============3539474158999219087==--