[pim] draft-ietf-pim-gaap-14 early Intdir review

[Sheng Jiang via Datatracker <[e-mail]>]

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.

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.

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.

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".