[pim] Re: [Int-dir] Re: draft-ietf-pim-gaap-14 early I ntdir review

Hi, Mike,


Your explanation are acceptable. More clarification on your design considerations would be helpful.


Cheers,


Sheng





                    Mike McBride<[email protected]&gt;&nbsp;On Friday,  Apr 17, 2026, 16:14 wrote:

Hi Sheng,


Thank you for the review. We will update the draft based on your comments. Please see my comments below:

On Thu, Apr 16, 2026 at 7:10 AM Sheng Jiang via Datatracker <[email protected]&gt; wrote:

Document: draft-ietf-pim-gaap
 Title: Group Address Allocation Protocol (GAAP)
 Reviewer: Sheng Jiang
 Review result: Ready with Issues
 
 Document: draft-ietf-pim-gaap
 Title: Group Address Allocation Protocol (GAAP)
 Reviewer: Sheng Jiang
 Review result: Ready with Nits
 
 I have reviewed this document as part of the IntDir directorate's ongoing
 effort to review all IETF documents being processed by the IESG. Comments that
 are not addressed in last call may be included in AD reviews during the IESG
 review. Document editors and WG chairs should treat these comments just like
 any other last call comments.
 
 This Experimental document describes a design for a lightweight 
 decentralized multicast group address allocation protocol. Overall, it is well
 written and in a good sharp. There are a several issues the authors could make
 improvements:
 
 In section 4, the Group Name is in variable length. The design only describe it 
 is "string is terminated with a null character." From the design perspective
 of a protocol. There is no way to decide how long it is and process the following
 unless process every bits from the start as characters. It is highly recommended
 to add a length field before, and padding bits at the end for alignment.


The group name's effective length can be determined from the overall message length minus the fixed fields. Implementations can parse the field without an explicit length. If no null terminator is found within the remaining message the packet would be dropped. Given the small size of GAAP messages and their infrequent processing we believe this approach is sufficient and avoids additional complexity in the encoding. We will clarify this behavior in the update.
&nbsp;
 In section 4, in GAAP Claim Message, there are both an IPv4 and an IPv6 address.
 But according to definition in section 2, a Group Address should be an IPv4 "OR"
 an IPv6 address. It is recommended to replace this two address fields by a field
 with "Address Family" flag. The flag would decide the length of the address field.


The current format includes both IPv4 and IPv6 fields to keep parsing simple and avoid introducing additional branching and error handling for unsupported or invalid AFI values. Only one of the fields is populated depending on the group type as defined in the document. We prefer to keep the existing format for simplicity and interoperability but we will make this behavior more explicit in the text.
&nbsp;
 In section 4, 32-bit timestamp in seconds is too small. It have the "year 2038"
 issue. It is highly recommended to use 64-bit timestamp.


The timestamp is intended to provide a relative ordering between competing claims rather than represent absolute time. Wraparound does not materially impact correctness as long as comparisons are done appropriately. We will add clarifying text to make this explicit.
&nbsp;
 In section 8, the draft claim "At this time there is no dynamic rekeying ... 
 Therefore, all nodes must be manually rekeyed". I understand the dynamic rekeying
 management is out of scope of this document. But it can be worked with other 
 existing DKM mechanisms. It is not wise to state "must be manually rekeyed".


We will update it to reflect that GAAP can operate with external key management mechanisms and manual rekeying is not the only possible approach.


thank you.
mike

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