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

I would include as a reference but wonder since it’s not an RFC it will hold up processing GAAP. 

Chairs?

Dino

> On Feb 25, 2026, at 6:30 PM, Toerless Eckert <[email protected]> wrote:
> 
> Nice!
> 
> And i didn't mean to suggest that SAP/SDP would have been a reasonable option,
> 
> I think to remember the early discussions of which direction to go with Nate,
> where i hope to remember correctly having said "mDNS or SAP/SDP could be
> used but that would be way too complex and unnecessary".
> 
> So i am very happy with GAAP as a protocol. Justs not that history paragraph
> because now with the -10 rev it's even more just a mind map.
> 
> Oh well...
> 
> Cheers
>    Toerless
> 
>> On Thu, Feb 26, 2026 at 11:09:19AM +0900, Hitoshi Asaeda wrote:
>> Although it is very old, the following document organizes SAP issues and problems or requirements related to multicast address or channel management.
>> 
>> https://datatracker.ietf.org/doc/html/draft-ietf-mboned-session-announcement-req-03
>> 
>> Regards,
>> 
>> Hitoshi
>> 
>> 
>>>> On Feb 26, 2026, at 9:39, Toerless Eckert <[email protected]> wrote:
>>> 
>>> 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] <mailto:[email protected]>
>>> 
>>> _______________________________________________
>>> pim mailing list -- [email protected] <mailto:[email protected]>
>>> To unsubscribe send an email to [email protected] <mailto:[email protected]>
> 
> --
> ---
> [email protected]

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