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

Hi Stig,
> 
> Thank you for your thorough review of draft-ietf-pim-gaap-06. We have incorporated your feedback and submitted version 08 of the draft. See diff file attached. Below are our responses to your comments:
> 
>>     In 2. Definition of Terms:
>> 
>>         GAAP Group Address: is an IANA assigned non-link-local group address
>>         the GAAP protocol sends messages to. This address must not come from
>>         the GAAP multicast address block allocated by IANA.
>> 
>>     Do we need to mention IANA and that it is not from the other block?
>>     This is explained in the IANA considerations. Isn't it sufficient here
>>     to just list the exact addresses. Maybe put TBD1 and TBD2 as
>>     placeholders?
> 
> We agree that this was unclear. We have updated the definition to specify the exact address ranges using TBD1/8 for IPv4 and TBD2/32 for IPv6, with a cross-reference to the IANA Considerations section. This makes it clear that GAAP Group Addresses must come from these allocated blocks.
> 
>>     In 4. GAAP Message Format:
>> 
>>     It is not clear to me what exactly the Timestamp is. Is 32 bits
>>     enough? Should it be 64 bits?
>> 
>>     Are records aligned or will the next record come immediately after the
>>     Group Name of the previous record?
> 
> 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.
> 
>>     In 7. Security Considerations:
>> 
>>     I believe all applications need to support the same encryption
>>     mechanism and have the same keys. This could be difficult in some
>>     cases. For instance I think it would be great if embedded devices that
>>     today use a fixed IANA assigned address could make use of GAAP
>>     instead.

> We have updated the Security Considerations section to explicitly state that all GAAP implementations should support the same encryption mechanism and use the same key management procedure to ensure interoperability. We also acknowledge that this could be difficult in embedded devices with different configurations, noting that this is an important consideration for adoption in legacy systems.
> 
>>     In 8.3.:
>> 
>>     A /8 block is requested from IANA, but this does not fit within the
>>     current blocks IANA is assigning from. We will need some discussion
>>     within IETF and with IANA on how to deal with this. This is a really
>>     big portion of the IPv4 multicast space. Does it need to be this
>>     large?

> We have added discussion in the IANA Considerations section to acknowledge that a /8 block represents a significant allocation from the IPv4 multicast address space and that discussion between IETF and IANA is needed to determine the appropriate block size. For IPv6, we clarified that the /32 allocation should come from the Dynamic Multicast Group IDs registry as defined in draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id.
> 
> All changes have been incorporated into draft-ietf-pim-gaap-08, which was submitted on February 13, 2026. We believe these modifications address your concerns while maintaining the protocol's core design principles.
> 
> Thank you again for the detailed review.
> 
> Best regards,
> Dino Farinacci
> Mike McBride
Claude Code



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