Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id C5EB94B for ; Wed, 28 Oct 2026 18:30:08 +0000 (UTC) Authentication-Results: mx.ietf.org; dkim=pass header.d=gmail.com header.s=20260707 header.b=DtjTAf6I; arc=pass ("google.com:s=arc-20260327:i=1"); spf=pass (mx.ietf.org: domain of chris.box.ietf@gmail.com designates 2a00:1450:4864:20::530 as permitted sender) smtp.mailfrom=chris.box.ietf@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-6acb9c018ffso2091599a12.1 for ; Wed, 28 Oct 2026 11:30:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1793212208; cv=none; d=google.com; s=arc-20260327; b=YZzSAlSqEwgdlEBxoevieIIVbdYNeulOj1emPKsaoldEAQYcb03zOQ9baPeMsSkeYy hcHmTXIMdH8Bsn2szV3iC2Qdg63h5tr2SYX4RO9s7k2DtbL7ZQ1pdK05ilz8dEfC9905 Z5VaaTVjzYr5/Q+2nkGi1CvXmwJsiSMYgQL0VvUDy9LqmMC4X1XdrXi6nsxkSGwqpEoE R4VGCI6Yyn4dkctWpHrTql+BzbhaO9vLtwyK0gkVIfByZI79iOznUeOAryGqXpTeBRGM 7cA0sFL06n9CLH+UNydqouwoYED6Y8xvoHiO1BE/NBaJljxQm7coe+AXNvQfJyTD/wcN 9oJg== 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=G2ymUGIzI6UJFsSK5dqiutP4EP0B70dFSC4kvFdRixU=; fh=/CYz4g8loo980XGq3Gd06vf9Mmn/HmFXQ/s8VH2pybA=; b=fcjEDco16hS0sNWHjQ+ikiW9nUTW1kF0siBNx/wNROYPw2A1WZMPuOSgu2aBqwMuzt RhwPIJ7M+hluelC2jvZGIAHFHZbryO7+ea0Tb93eUhFoxv3LpUN2DxZ3FFDpBv3f1F/Y fU1oh8PfI1PZlEtSYU8+UdwlE7D/LwVMiGqh+w8m64oLkoiRMHQJ3YuUs1BHCr61sJQJ iWKtxXN5T757ldXxVI9HitcKBJB0VcUiD5uhk+b+I0sPxa7OOYaYKrOmBzWwCj+DRU36 tXsZEIB2qndEFUL9EfsHgu5I2vXKcj/utWMBM0Hzr2qMA/xcYIzZs58c4uDncdS11xTq KGxA==; 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=20260707; t=1793212208; x=1793817008; 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=G2ymUGIzI6UJFsSK5dqiutP4EP0B70dFSC4kvFdRixU=; b=DtjTAf6I4fk7RQCw6Z9Cxufn/HLStvs+LAcYb3Au0iMbPAjjC0ZDiJtvPEtyql5kY4 8iie6ZSnCLoDc5uoKSsrmsotlM7nuxW/dAPw1b/MRLfOHUGzmlAtLaqGyMmh8DOWVP6v F9Y8H278jpauTbpnPP/ZXIbKS36LQ6UfhQzTliyQSSEpk23iNeiykv8jvsgjEaoygZsC xcTaEZveMgXtXoEq/TzLbn1Cg/JRr7XuquJdh5UdVHUGXHkPhAklSY5KbYDNY010FO24 o7w4IehoGyclY4U+sWObmVn8LY4gJC1lHMf/KdmfHr7iL/DNnmflKpiboG1E1qtm88nn MZxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793212208; x=1793817008; 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=G2ymUGIzI6UJFsSK5dqiutP4EP0B70dFSC4kvFdRixU=; b=LE5YT7wnkhFiZdfDqbz7WU2Vx0UPs4hDWc7U1VNiW+JDCeMdMeJE7j3zfXwrDV5DBw mds77qMrcElvJu9BDIa5fLxL1WtbCs/CmmeEs15SnJFwnhW0Tiun9znVbIuKubO2nnV0 SWdPQDMSKXqTGSMMDiW9udGA8MU+yCbod++PL+T58rZAa+VNPh5hs2Ap0zRrhgC6Itwv 1W+OlSoGx1G9ffqUcfW683pxVfAnCzb0wUuN01mR4Rjwn48HhtX5J/LE06BZ9Dcj1xed ZMBIoxPcHIlc+ZFVuirp14MTArMRstkNfA20vDc0+xj83BAFcXDYczXxYe+EKnM7NCe8 OuGA== X-Forwarded-Encrypted: i=1; AKwUvBwMKpqwXvq+8YjdUjj+ZX+/CgQN3MGwDjYQwXmsYoPTh9+B6GQURoEVOs/zEwFHIMZO9rqfeAM7UyA=@ietf.org X-Gm-Message-State: AFq9FYJn0wfqH1NykwkVLATLds8cSEuFaJB3c35ZBG5CWFHJn+KT2hB3 GEkYSu+Enl3kdLaY2n8DzxbhovtfcvG1ii5FaVe0NjKxK8nAlCeuGSOHUopRfS8fXocJxQj3Bsr wBqWDFumk7Qa1gk4VNa515g3TvRSgcFE= X-Gm-Gg: AYBFou2Im//UPNujEGgiJ5ntWMp4blbWGUM8d7Bs/32qIYiVw03ijcefnF6SksREwMs 1fLt4esuXHbHNd+piTfIrZjxfaP6vU5icukH3XT6smcVr8IJOwXPsqraS46nu57Ug8EI2KFEzNM bjAX21IwiuKAXqaqIKNPyV22Gc21yFqmWYiCYKI/DqNg57f8StLAx5dgtA3mY8+AlWAoUkVD3h+ S0G5YYb38ZVQ3+SdH4fzFuSgoKeLlg3gbl+cXjG6UYeB0Ddopm+q8LDWYj4LheSuMO+ozoSM2L1 pfEdco6AobfF8FWEPsGbjx/LY90CcnKAA1NzWmVhjoijqqAuk3I4Fg4rgZtIdmA1x9myKNnYg0r xzKBGuE94hR95z74FHoJaRk+Ec0uGyaWJc2WIreA= X-Received: by 2002:aa7:c617:0:b0:6aa:12f0:166e with SMTP id 4fb4d7f45d1cf-6b4b0b5a30emr239661a12.16.1793212207379; Wed, 28 Oct 2026 11:30:07 -0700 (PDT) MIME-Version: 1.0 References: <179256052312.561464.16033573705409864584@dt-datatracker-7457c9c988-pqlqx> In-Reply-To: From: Chris Box Date: Wed, 28 Oct 2026 18:29:56 +0000 X-Gm-Features: AclHuK93ysEOiQhv244idSZ8PUzdxyQVBDz_P_jKZGP7y4olkLn9fq0M4mcCLvY Message-ID: To: "Karstens, Nate" Content-Type: multipart/alternative; boundary="000000000000a0b930065eeac0a6" X-Spamd-Bar: --------------------- Message-ID-Hash: DAVC5V6COKNFR6ORHBV4TI2AAPNUODKA X-Message-ID-Hash: DAVC5V6COKNFR6ORHBV4TI2AAPNUODKA X-MailFrom: chris.box.ietf@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "int-dir@ietf.org" , "draft-ietf-pim-ipv6-zeroconf-assignment.all@ietf.org" , "last-call@ietf.org" , "pim@ietf.org" X-Mailman-Version: 3.3.10 Precedence: list Subject: [Last-Call] Re: draft-ietf-pim-ipv6-zeroconf-assignment-13 telechat Intdir review List-Id: IETF Last Calls Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000a0b930065eeac0a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 27 Oct 2026 at 18:43, Karstens, Nate wrote: > > There is of course a massive installed base of managed switches that can > do multicast snooping. They don't currently support publishing veto > records. Does this document introduce a new type of managed switch that c= an > initiate vetos? > > > > You say that use of these new veto-supporting switches is not required. > Therefore it also needs to describe what might happen with existing > multicast-snooping switches. > > > > NK> We added a new subsection describing this scenario and how address > conflicts can still be resolved. Please let us know what you think. > Section 3.1 is a fantastic addition. The clear guidance for implementers really helps. You describe where the dragons might be, and some ways to handle them. It sounds like the "external tool" is going to be many people's first choice, if one is available. How sure are you that the description of the tool's actions is correct? I wouldn't want this to become an RFC and then need some changes. If a proof of concept tool can be created relatively quickly, and you can force two devices to use the same group ID, then you might be able to give a firm thumbs-up that this is the right description. > > > Is there an installed base of implementations that randomly pick groups > from 0x80000000 =E2=80=93 0xFFFFFFFF? If so, they have a 1-in-8 chance of= picking a > 0x90000000 address, unless/until they are updated with knowledge of RFC > 10028. > > > > NK> We did look into MADCAP and our research showed that it only has a > single implementation and is not widely deployed (see Acknowledgements in > RFC 10028). As such, we don=E2=80=99t think there is a lot of benefit to = describing > this scenario. What do you think? > Perhaps add a sentence referring to 10028 section 4's "*Any existing deployments of MADCAP should either use an updated implementation or operate in an environment without*" this new zero-configuration protocol. Then I agree you are covered. > > I think you agree with me: it enables skipping generating a random group > ID. This means the phrase "does not permit the application to skip any of > the preceding steps." is a little misleading. You're right that section > 2.1 still needs to happen, but the core part of section 2.1 is skipped. > This only needs a little clarification text and it'll be fine. > > > > NK> Makes sense, please see the updated text. > I'm happy with this. Chris --000000000000a0b930065eeac0a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, 27 Oct 2026 at 18:43, Karstens, Nate <Nate.Karstens@garmin.com> wrote:
<= div class=3D"gmail_quote gmail_quote_container">

= There is of course a massive installed base of managed switches that can do= multicast snooping. They don't currently support publishing veto recor= ds. Does this document introduce a new type of managed switch that can init= iate vetos?

=C2=A0

You say that use of these new veto-supporting switch= es is not required. Therefore it also needs to describe what might happen w= ith existing multicast-snooping switches.

=C2=A0<= /span>

NK> We added a new subsection describing this scenario and how address = conflicts can still be resolved. Please let us know what you think.


Section 3.1 is a fantastic addition. The clear guidance for impleme= nters really helps. You describe where the dragons might be, and some ways = to handle them. It sounds like the "external tool" is going to be= many people's first choice, if one is available.

<= div>How sure are you that the description of the tool's actions is corr= ect? I wouldn't want this to become an RFC and then need some changes. = If a proof of concept tool can be created relatively quickly, and you can= =C2=A0force two devices to use= the same group ID, then you might be able to give a firm thumbs-up that th= is is the right description.
=C2=A0

=C2=A0

Is there an installed base of implementations that r= andomly pick groups from=C2=A00x80000000 =E2=80=93 0xFFFFFFFF? If so, they = have a 1-in-8 chance of picking a 0x90000000 address, unless/until they are= updated with knowledge of RFC 10028.

=C2=A0<= /span>

NK> We did look into MADCAP and our research showed that it only has a = single implementation and is not widely deployed (see Acknowledgements in RFC 10028). As such, we don=E2=80=99t think there= is a lot of benefit to describing this scenario. What do you think?=


Perhaps add a senten= ce referring to 10028 section 4's "Any existing deployments of = MADCAP should either use an updated implementation or operate in an environ= ment without" this new zero-configuration protocol. Then I agree y= ou are covered.

=C2=A0

I think you agree with me: it enables skipping gener= ating a random group ID. This means the phrase "does not permit the application to s= kip any of the preceding steps." is a little misleading. You're right that section 2.1 still needs to happen, but t= he core part of section 2.1 is skipped. This only needs a little clarificat= ion text and it'll be fine.

=C2=A0<= /span>

NK> Makes sense, please see the updated text.


I'm happy with this.

=
Chris

--000000000000a0b930065eeac0a6--