[Last-Call] Re: draft-ietf-pim-ipv6-zeroconf-assignment-13 telechat Intdir review

[Chris Box <[e-mail]>]

On Tue, 27 Oct 2026 at 18:43, Karstens, Nate <[e-mail]>
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 can
> 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 – 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’t 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