Return-Path: X-Original-To: pim@mail2.ietf.org Delivered-To: pim@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 276B3118AB6C8 for ; Fri, 17 Jul 2026 19:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784340870; bh=eUZ4J96UVCJBVc+CppeHk82yIGq7YKVXjkZEQrKtz10=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=bKJdLLzrYa8hZrv8YELokbUPICH21PEYpE18NDtDMXWOZK1guKAucWqpUVfkhDFqH llJnTOtzAone1cG/K8HgYNCF6CblNVcmjDUrEeKnH/HTdfKozg2p0wooYT733OqO5E Lq45fG1WkTAf6MP81klcEYpqKPuY6sB65Pgtfor4= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbJKGrjA7AJJ for ; Fri, 17 Jul 2026 19:14:29 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 8CB69118AB6B2 for ; Fri, 17 Jul 2026 19:14:29 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-69c5eb6dfd3so11968676a12.3 for ; Fri, 17 Jul 2026 19:14:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784340868; cv=none; d=google.com; s=arc-20260327; b=Aa31KYZt0r8LOk0dqJV7HwIKW1BY0Y5jAjchAuDR2gWiXMViaCnERq+LiZc0j9bTai I+seOfoiTs/Md/4zKDo/oczTLllB1C5//ilkuhP2n2ihH7id8XwbKvXLUx0m4bgU35Th WJAyTmuFtFgU2qfotxd0EcBlsa344ELCBCxMYywsY2FPXnhMJVPSJ+K4jJ65DBqM2C90 Pl+PnK2xnftRvm1Y+vqhD4bUG0QtcXZ6n9XT9DZNbg6Ozp+eTd6HRXD7AMXJGXTP33uA xyHaNx1e0G5NIQhq8rylFeWOoJ89aA6v0OZQQUF3WGfRdXRLxGY4zTa2IA9GM5oYICKQ CqFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=X4XNIhfPKw0MDdo5b90cck5c8U9PrCmVTjegE+K38Qk=; fh=/8i4Fhf5FbmJPTAFaLj73VQUAv9pVaOb0bs4folqSxM=; b=Wg7p6wgISbiRYRENsgCllaKGcR6scmotCTEjEkJ2ABU0JAZMyYjRNTWpVPj57Rv0dd gCOOksksrb7K+kheotXGT1i/fxv5luSUO7chr3aayFm6aBDHXM/vHxKEWE9DJUk1DaLF /PSWw6IMEa2r34SEjlLMf02osjrFKGQtj1qJ64BkObRt0AG83xSgV6KqsxhWfxg/1xoM qK/LxJqsM9NRx5mkrFDUHlPe88XLI5RBl3gEFNn1NtWbTanThRZLtIu8jpCBkyWGALn8 vTzXaAmlPUsAvKIoG6+S6erhj3vOqWa9Q+pOtckQlm97FtkvmKYLkAT32YhGNtEL+urr rrVA==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784340868; x=1784945668; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=X4XNIhfPKw0MDdo5b90cck5c8U9PrCmVTjegE+K38Qk=; b=lYkww87DP8XqalxW8pYLjfkL4OoHK98U2Akesr00iQyh7lAlZkxf+ufARVVL0cDp0f gfx8iB7R8mv5GQhQS3Y6uNT51R9GEjJJy+cx/IEIIGCYIPteLG1K3GqW1nGaXD7O/RWC ff4iaOGSrI8Pa2nlzS5f6bKAnVrQ6wY+S9crUqXgQ4ZV1f8BOoyg7UMbumDaegWMqZzT r+TaLdAqd/Rt9QqZresI5uoGOyRJ1G/nMEirGSQvGcitxnCrBRj50FMpaq59tgnfg1Mq dnZD4CkQwU8ekSULcprW46oov13lWvqRVwK6wwZt8L9BSypYM1K93GH7iO4WcXNWUNDO mq/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784340868; x=1784945668; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=X4XNIhfPKw0MDdo5b90cck5c8U9PrCmVTjegE+K38Qk=; b=CqSMp3v40JVIANJfSO8rVM6zjCQBCgQqbSseMxMjJ87rYQDsjeE/CzqIwm7ro/12kk IaPBRaQYoVrh3sxnnjXZvlErHB1/cHVUVsQ3DWlqBUz2rh3YYxLXzndofk63IxsZ8APW D3lxWF1c55suB+XLYPifM9z/++h7zAdsj0tQa/6vhG4qCsD8M0gdM7e9b96bkqPO7D9G u6TTWSe8xWx5lHgu/4WZorCFry7Mtz4M+rSSgAX2WNFc9sIrD+NKxVVzFw8ya7pc9AmX V7XBmiJgn78IttrSLhi/dP9xHOtfEVRzlF6XOmgwFPARYGBPVdKV13STq46uNt/ZfN0V RSVA== X-Forwarded-Encrypted: i=1; AHgh+RpwvQPhzeOW03eDt5okD71+HmwQHsScAbikOVdD9ffZd+157kpBgfgqaz90DJio6zOWeKk=@ietf.org X-Gm-Message-State: AOJu0YwiPE3v7lXXWL0/6B7pKj55TxXGEWhwOpIbQWL0EofTEHajmI2Q EGcWbpjvf0ApuojTDxRdtlgu9nMKcevz1lxLEccMW61dbbBNXxNvimjfmBSNkQkkZEYHUwSxS7I tXEwnQa3pVS6Ue+aydt1ESe5aMZnY5Cw= X-Gm-Gg: AfdE7cmrQqvcMX8SYTDQBhRLK4vUOGstarSypLN6z3VKsJhHjGMGFxfdNYlObJkPlWd EUIm+U4unmcefnG5NEnnnqJwz8R3hqpHEnJ/h1B/Ql7W6lhCdRgKd+G8KhFmYU8Up3X8FYQbTWf db+UrH5k3jfHYd5aXIkJj/ON+Bbw/g21OLf294fY077Ge7jdvWM3lcnr+TJ7P13yu7BTrDz5IR4 AkCjkMknWxURuf5K3TSeNmGPZIAwT1zUAdmSY9ZwI6ScJFjbK3h+r5edH9nNFEuTRptyySp1dlH J47TL/dguSC9PMffFnZMwf1nznM= X-Received: by 2002:a05:6402:5054:b0:69a:2ee6:4c95 with SMTP id 4fb4d7f45d1cf-69e65163b60mr1729101a12.0.1784340868533; Fri, 17 Jul 2026 19:14:28 -0700 (PDT) MIME-Version: 1.0 References: <178395806553.474007.8923063342984360768@dt-datatracker-d4d6ff9d9-kg6bf> <6474A260-F227-402D-ACB7-C37E8254E48A@apple.com> <9AC8EA34-EF6D-4505-8D0D-FB3A818C5D3E@gmail.com> In-Reply-To: <9AC8EA34-EF6D-4505-8D0D-FB3A818C5D3E@gmail.com> From: Mike McBride Date: Sat, 18 Jul 2026 04:14:17 +0200 X-Gm-Features: AUfX_mwFcfLl5NKefY8m10saSPEf1ImYDQzEYmRldMcVjOgTDZs9TtyZmzjyl0I Message-ID: To: Dino Farinacci Content-Type: multipart/alternative; boundary="000000000000a091850656d93b6c" Message-ID-Hash: MR7EFSOUGADM67FTTASOMZN3I43SKAMR X-Message-ID-Hash: MR7EFSOUGADM67FTTASOMZN3I43SKAMR X-MailFrom: mmcbride7@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pim.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Nico Cvitak , last-call@ietf.org, draft-ietf-pim-gaap@ietf.org, gunter@vandevelde.cc, pim-chairs@ietf.org, pim@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bpim=5D_Re=3A_Last_Call=3A_=3Cdraft-ietf-pim-gaap-18=2Etxt=3E_?= =?utf-8?q?=28Group_Address_Allocation_Protocol_=28GAAP=29=29_to_Experimenta?= =?utf-8?q?l_RFC?= List-Id: Protocol Independent Multicast Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000a091850656d93b6c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Dino Farinacci wrote: > Some quick replies. > > > On Jul 17, 2026, at 9:20=E2=80=AFAM, Nico Cvitak wr= ote: > > > > 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 differen= t > encryption configurations, or lack > > These would be different domains that don't connect to each other. You ca= n > 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 tex= t > in section 8, which doesn=E2=80=99t 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 encryptio= n > 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=E2=80=9D? > > 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 shar= e > the same encryption configuration? > > I thought we had something like that. I'll leave this for Mike and Stig t= o > comment about. > > Dino > > > > > Thanks, > > Nico > > > >> On Jul 13, 2026, at 11:54=E2=80=AFAM, The IESG wrote: > >> > >> > >> The IESG has received a request from the Protocols for IP Multicast WG > (pim) > >> to consider the following document: - 'Group Address Allocation Protoc= ol > >> (GAAP)' > >> 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 > >> last-call@ietf.org mailing lists by 2026-08-03. Exceptionally, > comments may > >> be sent to iesg@ietf.org 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 protoco= l > >> requires no centralized service and minimal configuration, although > >> deployments using encryption or administrative scoping may require > >> configuration. The protocol runs among group participants which nee= d > >> 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 -- pim@ietf.org > >> To unsubscribe send an email to pim-leave@ietf.org > > > > --000000000000a091850656d93b6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nico,

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

mike
<= br>
On Fri, Jul 17, 2026 at 9:53=E2=80=AFPM Dino Farinacci <= farinacci@gmail.com> wrote:
Some quick replie= s.

> On Jul 17, 2026, at 9:20=E2=80=AFAM, Nico Cvitak <ncvitak@apple.com> wrote:
>
> Hi,
>
> I think this draft is a great step forward for multicast address alloc= ation, but I have some comments regarding section 8.

Thanks.

> How are collisions meant to be resolved across GAAP nodes with differe= nt 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 bound= aries so the well-known groups stay disjoint.

> thereof? It sounds like they'd just be allowed to collide given th= e text in section 8, which doesn=E2=80=99t 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 key= s.

> I'd imagine that applications wanting to use GAAP as a zero config= uration multicast address allocation protocol as highlighted in [I-D.ietf-p= im-zeroconf-mcast-addr-alloc-ps] would just not use encryption for "ze= ro configuration=E2=80=9D?

Right, a tradeoff between plug-and-play and secure communication.

> Perhaps section 8 should be amended to only suggest encryption when de= ployed in a coordinated administrative domain where all GAAP nodes share th= e 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=E2=80=AFAM, The IESG <iesg-secretary@ietf.org&g= t; wrote:
>>
>>
>> The IESG has received a request from the Protocols for IP Multicas= t WG (pim)
>> to consider the following document: - 'Group Address Allocatio= n Protocol
>> (GAAP)'
>>=C2=A0 <draft-ietf-pim-gaap-18.txt> as Experimental RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solic= its final
>> comments on this action. Please send substantive comments to the >> last-call@= ietf.org mailing lists by 2026-08-03. Exceptionally, comments may
>> be sent to iesg= @ietf.org instead. In either case, please retain the beginning
>> of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>=C2=A0 =C2=A0This document describes a design for a lightweight dec= entralized
>>=C2=A0 =C2=A0multicast group address allocation protocol (named GAA= P and
>>=C2=A0 =C2=A0pronounced "gap" as in "mind the gap&qu= ot;).=C2=A0 The base allocation protocol
>>=C2=A0 =C2=A0requires no centralized service and minimal configurat= ion, although
>>=C2=A0 =C2=A0deployments using encryption or administrative scoping= may require
>>=C2=A0 =C2=A0configuration.=C2=A0 The protocol runs among group par= ticipants which need
>>=C2=A0 =C2=A0a unique group address to send and receive multicast p= ackets.
>>=C2=A0 =C2=A0Tailored for IPv4 and IPv6 networks, this design offer= s a simple,
>>=C2=A0 =C2=A0lightweight option rather than extending an existing p= rotocol.
>>
>>
>>
>>
>> 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 -- pim@ietf.org
>> To unsubscribe send an email to pim-leave@ietf.org
>

--000000000000a091850656d93b6c--