[pim] Re: Suggestion: Re: Re: pim WGLC for draft-ietf- pim-gaap-06

The existing paragraph is actually pretty bad and would just get worse by this.

MADCAP and MASC are not zeroconf, and RFC3307 only points to one never
finished zeroconf draft (ZMAAPDOC). And the paragraph is also contradicting
itself with "require global scope ... use of a single subnet".
So those three solutions shouldn't even be mentioned.

But readers could reasonably question why not to use either of the two
successfully deployed approaches mDNS and SAP/SDP for this purpose.
That is IMHO the answer the "history" paragraph should answer if anything.

How about replacing the existing paragraph with:

mDNS {{RFC6762}} and SAP ({{RFC2974}} together with SDP ({{RFC4566}}) are
pre-existing protocols that could support zeroconf allocation of IP multicast
addresses, even avoiding MAC address collisions, but they have different and
much broader goals than just IP multicast address allocation and would
make IP multicast address allocation more complex, slower and likely less
reliable.

Cheers
    Toerless

On Wed, Feb 25, 2026 at 12:28:13PM -0800, Dino Farinacci wrote:
> How about, rather than going off on a tangent, which I think doesn't add that much value about group allocation, just add SAP/SDP to the list. So how about this text:
> 
> Other approaches to multicast group allocation have been proposed in
> the past, they include SAP [RFC2974], SDP [RFC4566], mDNS [RFC6762], MADCAP [RFC2730], 
> MASC [RFC2909], and IPv6 Allocation Guidelines [RFC3307].  However, they
> require global scope adding latency, configuration, use of a single subnet, 
> and are not decentralized.
> 
> Thanks,
> Dino
> 
> > On Feb 25, 2026, at 12:21 PM, Toerless Eckert <[email protected]> wrote:
> > 
> > Btw:
> > 
> > Just going through Sandy's review for rfc1112bis and would suggest
> > to add a paragraph the existing history paragraph:
> > 
> >   Other approaches to multicast group allocation have been proposed in
> >   the past, they include mDNS [RFC6762], MADCAP [RFC2730], MASC
> >   [RFC2909], and IPv6 Allocation Guidelines [RFC3307].  However, they
> >   require configuration, used on a single subnet, and are not
> >   decentralized.
> > 
> > Something like this:
> > 
> >   Previously, SAP ({{RFC2974}} together with SDP ({{RFC4566}}) could support
> >   zeroconf allocation of addresses, even avoiding MAC address collisions,
> >   but SDP was not designed solely for IP multicast address allocation but complete
> >   multimedia application session description and announcements, threfore
> >   introducing significant undesired overhead for applications that do not
> >   require such descriptions but only address allocation. Likewise, SAP
> >   was optimized for global scope IP multicast, hence requiring significant
> >   amount of time to discover all IP multicast addresses that are in use.
> > 
> > Cheers
> >    Toerless
> > 
> > On Sun, Feb 15, 2026 at 01:45:57PM -0800, Dino Farinacci wrote:
> >> Submitted -09. Here is the changed text:
> >> 
> >> 
> > 
> > 
> >> 
> >> 
> >> Dino
> >> 
> >>> On Feb 14, 2026, at 1:08 PM, Stig Venaas <[email protected]> wrote:
> >>> 
> >>> Thanks Dino. Changes look good, just one thing.
> >>> 
> >>> 
> >>> On Fri, Feb 13, 2026 at 2:12 PM Dino Farinacci <[email protected]> wrote:
> >>> [...]
> >>>> We have clarified that the Timestamp is a 32-bit standard epoch UTC timestamp in seconds per RFC 8536. We also added documentation that records may not be aligned and the Group Name field follows immediately after the Timestamp field.
> >>> 
> >>> You misunderstood what I wrote here. I think it is good to point out
> >>> that a record starts right after the Group Name field of the previous
> >>> record.
> >>> 
> >>> For the address space section and reviews, should we maybe see if
> >>> mboned has thoughts on the address space? Should we try to get some
> >>> directorate reviews before requesting publication? Maybe routing area
> >>> and int area makes sense?
> >>> 
> >>> Can you authors (and anyone else who might know) state whether you are
> >>> aware of any IPR?
> >>> 
> >>> Thanks,
> >>> Stig
> >> 
> > 
> > 
> > -- 
> > ---
> > [email protected]
> 

-- 
---
[email protected]

_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]