# Éric Vyncke INT AD comments for draft-ietf-pim-gaap-20
CC @evyncke

Thank you for the work put into this document. I find the idea so simple, but possibly not that scalable due to the collisions.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Stig Venaas for the shepherd's write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### ASCII-only group name

As the group names are likely to appear on a human UI, the group name must allow for non-ASCII, i.e., something like UTF-8 is required (of course, the null-terminated string probably do not work anymore).

### Well-known GAAP port

In section 4, there is `destination port is a well-known port allocated by IANA` and I agree with the IANA expert review `I recommend this be revised to use the multicast application port number assigned per draft-ietf-intarea-multicast-application-port. That draft recognizes that multicast services are already sufficiently differentiated by IP address and thus assigning new port numbers for multicast services is not necessary.`. I.e., there is no need to have a specific UDP port.

Therefore section 9.1 must be removed.

### Section 4

There is no specification about how to implement `the Marker field is used to indicate to a receiver that the packet may be encrypted. ` as this field has a fixed value and is never encrypted.

### Section 9.3

Several unrelated issues on this section (this was to be expected ;-) by the authors of course).

Please give IANA some indication about the IPV4 range to be used. It seems that https://www.iana.org/assignments/multicast-addresses#multicast-addresses-9 have still a lot of available /8, i.e., should GAAP use a /10 out of one /8 ? There is still a lof of available mcast IPv4 addresses as opposed to IPv4 unicast address, so, this is a problem for the wealthy.

Please split this section into one for IPv4 and one for IPv6, this will be clearer and easier to process.

The actual semantic of `This new registry requests the division of the 32-bit group ID range 0xA0000000 through 0xAFFFFFFF.` is unclear to me.

Finally, please use RFC 10028.

Thanks to the authors and the WG for their work on this document.

Note: Both the discussion points and comments are provided inline in the 
idnits output of v20. Lookout for the <EoRv20> tag at the end to ensure you
are seeing the full review.

<discuss-1> No suppression in the event of collision

Section 6.2

558	   When the timer expires, a Claim message is sent.  Suppression is per
559	   group address: receivers of a Claim message for a given group address
560	   who have their own timer running for that same group address reset
561	   that timer, thereby suppressing sending their own Claim message for
562	   it; timers for other group addresses the node is claiming are
563	   unaffected.  This allows only a single GAAP node that is using the
564	   group address to keep claiming the group is still in use.

A collision is, by this document's own definition at lines 546-549, the
same group address allocated to two different group names. The
suppression rule above is keyed on the group address and says nothing
about the group name. Read as written, a node using address X for name
A, on receiving a Claim for X carrying name B, has its own timer running
for that same group address, so it resets that timer and thereby
suppresses the very message the new node is waiting for. The new node
hears nothing within its window and starts using the colliding address. 
Two implementations will diverge on whether the suppression rule or the 
collision rule governs.

Suggest:
   When the timer expires, a Claim message is sent. Suppression is per
   (group name, group address) pair: a receiver of a Claim message that
   carries both the same group address and the same group name as one
   the receiver is claiming resets its own timer for that pair, thereby
   suppressing its own Claim for it. A Claim message that carries the
   same group address with a different group name is a collision and
   MUST NOT suppress the receiver's timer; the receiver processes it per
   Section 6.1 and responds as described below. Timers for other group
   addresses the node is claiming are unaffected.

<discuss-2> Computation of the hash

Section 2 and Section 6.1

177	      Hashed Value:  is the output of a SHA-256 [RFC6234] hash function
178	         where the low order 32-bits are used to produce a network layer
179	         multicast group address that is unique among the group names in
180	         use.

479	           hash = sha256(group_name)
480	           low_bits = hash & 0xffffffff

SHA-256 produces a 32-octet string, not an integer, and RFC 6234 defines
no integer interpretation of it. Neither "the low order 32 bits" nor the
masking operation in the pseudocode says precisely enough which four octets
are taken or in what order they are assembled. Implementations that choose
differently derive different addresses from the same group name and
never rendezvous - no error, no collision detected, silent failure.
Everything in GAAP rests on this one mapping being identical everywhere.

Suggest:

   Hashed Value: the group name is hashed with SHA-256 as specified in
   Section 4.1 of [RFC6234], producing a 32-octet message digest. Number
   the octets of that digest from 0 to 31, octet 0 being the first octet
   output by the algorithm and octet 31 the last. The Hashed Value is
   the 32-bit unsigned integer formed from the last four octets of the
   digest, taken in network byte order: digest octet 28 is the most
   significant octet, octet 29 the next, octet 30 the next, and octet 31
   the least significant.

Which four octets are used is the authors' choice; saying which is the
requirement. 

One other related bit: state the hash input exactly. Section 4 makes the 
on-wire Group Name null-terminated without saying whether the terminating 
null is part of the hash input.

<discuss-3> Timestamp - ahead or before or both ?

Section 4, the normative home:

327	         disciplined source for the Timestamp where available.  A
328	         Timestamp that appears to be more than a small, locally
329	         configured skew allowance ahead of the receiver's own clock
330	         SHOULD be treated with the same tie-breaking rule as an equal
331	         timestamp rather than assumed to win outright, since it may
332	         result from a misconfigured or unsynchronized clock (including
333	         a clock that has not yet been set after boot, which typically
334	         reads a value far in the past or at zero).

Section 8, a different rule:

836	      from it.  A Timestamp that appears to be more than a small,
837	      locally configured skew allowance ahead of, or behind, the
838	      receiver's own clock SHOULD be treated with the same tie-breaking
839	      rule as an equal timestamp rather than assumed to win or lose
840	      outright, since it may result from a misconfigured or
841	      unsynchronized clock, including a clock that has not yet been set
842	      after boot, which typically reads a value far in the past or at
843	      zero and would otherwise win every collision it is party to.

Section 6.3 sends the reader to Section 4:

596	   fixed.  The group address with the earliest Timestamp is used to
597	   determine who keeps the collided group address, using the same
598	   comparison and tie-breaking rule defined in Section 4 for equal or
599	   skewed Timestamps.

Arbitration is earliest-wins (lines 526-530), so the problematic direction
is behind - and Section 4 covers only ahead, naming the unset-clock case
in a parenthesis without handling it. An implementer follows Section 4
and Section 6.3, which are the specification sections; only Section 8
carries the working rule.

Suggest: please make Section 4's rule symmetric - "ahead of, or behind, the
receiver's own clock" - and reduce Section 8's paragraph to a
cross-reference plus the attack rationale.

<discuss-4> Same marker for encrypted and unencrypted?

Section 4 and Section 8

283	         0xAAAAAAAA.  If it is not, the packet is dropped.  The Marker
284	         field is used to indicate to a receiver that the packet may be
285	         encrypted.  See Section 8 for details on encrypting GAAP
286	         messages.  When encryption is used, the Type, Reserved, and
287	         Record Count fields, together with the Marker field itself,
288	         remain in cleartext so the receiver can identify the packet as
289	         GAAP and detect the encrypted condition before attempting
290	         decryption; the record data that follows the Marker (addresses,
291	         Timestamp, and Group Name) is encrypted.

769	   embedded devices with different configurations.  The message Marker
770	   is always sent in cleartext as 0xAAAAAAAA (see Section 4) and is used
771	   by the receiver to identify the packet as GAAP before determining
772	   whether the following record data is encrypted.

791	   senders sharing that key.  A receiver configured with a shared key
792	   MUST reject an unencrypted Claim message rather than process it, to
793	   prevent downgrade to the unauthenticated base mode.

The Marker is a constant - 0xAAAAAAAA in both modes, as line 770 says -
so it carries no information about whether the record data is encrypted,
yet lines 284 and 288-290 give it that job. Type, Reserved and Record
Count are the only other cleartext fields and none of them is defined
for this, so there is no encryption indication anywhere in the header.
The MUST at line 792 therefore places a requirement on a discrimination
the receiver cannot make, and the stated protection against downgrade to
the unauthenticated base mode does not exist.

Two ways (that come to my mind) to address and I prefer the first:

1) Signal it. Allocate one bit of the 20-bit Reserved field as an "E"
   flag, set by the sender when the record data is encrypted, and define
   receiver behaviour for each combination of (E flag, key configured).
   This needs a registry for the Reserved bits - see discuss-9.

2) Make it configuration. State that encryption is a deployment-wide
   configuration, that a receiver processes according to its own
   configuration, and that a mixed deployment does not interoperate -
   then delete lines 284 and 288-290.

Either way, please correct the Marker description: it is a format check
for a well-known-port UDP listener, as Section 8 already says at lines
787-789.

<discuss-5> Unclear scope and applicability - Routed multicast admin domain OR
IP subnet/LAN domain

Abstract:

15	   pronounced "gap" as in "mind the gap").  The base allocation protocol
16	   requires no centralized service and minimal configuration, although
17	   deployments using encryption or administrative scoping may require
18	   configuration.

Section 7, positioning:

649	   GAAP is intended for zeroconf and unmanaged or loosely managed
650	   deployment scenarios, such as those described in [RFC10019], where
651	   applications need a group address without relying on centralized
652	   configuration or provisioning.

Section 7, requirements:

741	   GAAP requires the underlying network to support IP multicast group
742	   membership (IGMP/MLD) and ASM-capable multicast routing/forwarding
743	   (e.g., PIM-SM) for delivery of Claim messages.

747	   address has been allocated and claimed via GAAP.  In IPv4 deployments
748	   using PIM-SM, the Rendezvous Point(s) serving the GAAP Group Address
749	   and the GAAP IPv4 allocation range need to be configured to support
750	   the full range described in Section 9, since a GAAP node may allocate
751	   any address within it.

A PIM-SM RP is a centralized service and a single point of failure,
and covering the GAAP range with RP mappings is administrator
configuration - against RFC 10019's REQ-2, REQ-3 and REQ-6, and
against the Abstract at lines 16-17. Section 9.2 pulls the same way by
requiring an admin-local or organization-local IPv6 control scope so
that Claims can cross links (lines 884-887). It is not clear if the document is
describing two deployments and which properties are being asserted for which.

Is GAAP intended for a single link or IP subnet, or for a routed
multicast administrative domain?

   If the former, the zeroconf framing and "requires no centralized
   service" hold, no RP is involved, and lines 741-751 describe a case
   that is out of scope rather than a requirement - please say so and
   scope Section 7 accordingly.

   If the latter, the deployment depends on the domain's ASM routing
   including RP coverage of the GAAP range, that coverage is
   administrator configuration, and the zeroconf property does not
   hold - please say so, correct the Abstract, and state what the
   relationship to RFC 10019 then is.

   If both are intended, please state each separately with the
   properties that apply to it.

The answer also determines which IPv6 address formats a GAAP address may
take (discuss-7), whether a globally scoped IPv4 range is needed at all,
and how wide the first experiment should be.

<discuss-6> An unrecoverable error for which operator is not alerted

Section 6.1

510	           # All 4 candidate addresses (see "Acceptable Group Hash
511	           # List" in Section 2) collided. gaap.allocate() returns
512	           # an error to the calling application; the application
513	           # MAY retry later or select a different group name.
514	           return(None)

516	   If all 4 candidate addresses for a group name collide, the GAAP API
517	   returns an error to the application, as shown above.  GAAP does not
518	   define automatic retry behavior in this case, since retrying with the
519	   same group name would deterministically produce the same 4 candidate
520	   addresses.

The failure is permanent for that group name in that domain, and the 
only remedy offered is "select a different group name" - which every
participating node must also do, out of band, with no coordination 
mechanism. Is that ok for embedded devices with a compiled-in name?

Nothing surfaces the condition either - Section 7 asks implementations
to expose local claim state (lines 691-693) but says nothing about an
exhausted name.

Please require the condition to be logged and exposed through the local
management interface Section 7 already asks for - at minimum the group
name, the four contested addresses and the claimants - so that the
failure is diagnosable rather than silent. Separately, the document
should say what a deployment is expected to do when this happens, rather
than leaving "select a different group name" as the whole answer; what
that should be is for the authors and the WG. Was this case discussed?
The text reads as though it was noticed and then accepted without a
remedy.

<discuss-7> Questions on derivation of IPv6 Group Addresses

Section 6.1 and Section 9.3

494	   For IPv6, the resulting 128-bit group address is a multicast address
495	   per [RFC4291] with the flags and scope bits fixed by the IANA-
496	   assigned GAAP_V6_BASE (see Section 9) and the 32-bit Group ID placed
497	   in the low-order 32 bits, matching the low-order 32 bits produced by
498	   the hash.  No other bits of the address vary.

903	   deployment scales.  For IPv6, a /32 block in a new registry range is
904	   being requested, sized to match the 32-bit Group ID used directly in
905	   the hash-based derivation in Section 6; the larger IPv6 multicast
906	   address space makes collision probability far less of a concern than
907	   for IPv4.

This seems internally contradictory. Section 9.3 asks for the IPv6 range
out of the "Dynamic Multicast Group IDs" registry, whose entries are
sub-ranges of the 32-bit group ID. If the GAAP range is a sub-range,
only the bits below its prefix are available, and line 498's "no other
bits of the address vary" is unachievable. The pseudocode names a
GAAP_V6_MASK (line 490, and prose at lines 476-477) that line 498 then
contradicts, leaving an implementer with two mutually exclusive
statements of the same derivation.

There is also a routing consequence. Fixing the whole 96-bit prefix
means a GAAP IPv6 address can be neither an RFC 3306
unicast-prefix-based address nor an RFC 3956 embedded-RP address, both
of which use bits 32-95 - and embedded-RP is the dominant way IPv6 ASM
RP discovery is done. Every deploying domain would then need a globally
agreed static or BSR-learned RP mapping for the one fixed GAAP prefix.
That is unstated, and it is also inconsistent with taking the range from
a group ID registry, whose premise is that the prefix varies per
deployment. How much it matters depends on the answer to discuss-5.

Suggested replacement:

   For IPv6, GAAP derives only the group ID. The group ID is formed by
   placing the low-order bits of the Hashed Value into the host portion
   of the GAAP group ID range, in the same manner as the IPv4 derivation
   in this section. The remaining bits of the multicast address - flags,
   scope, and, where the RFC 3306 or RFC 3956 formats are in use, the
   embedded prefix or Rendezvous Point information - are determined by
   the deployment and are outside the scope of this document, other than
   the scope constraint in Section 9.2.

Please also state how many hash bits the chosen group ID range leaves
available, and which address formats a GAAP IPv6 address may take. How
the range is obtained is discuss-8.

<discuss-8> Issues with IANA Considerations

Disclaimer: I faced serious challenges in deciphering this and it is
possible that I have misunderstood; this section needs quite a lot of
work.

Section 9

None of the three IANA requests in this section can be executed as
written, and the section conflates creating a registry with assigning
from one. Lets go over the points one by one:

(a) The section contradicts itself about the kind of action requested.

853	   IANA is requested to make the following assignments in existing
854	   registries:

858	   IANA will create one UDP port number for the GAAP protocol,

875	   IANA will create one multicast address from the IPv4 Internetwork
876	   Control Block 224.0.1.x [RFC5771] and one multicast address from the
877	   IPv6 Variable Scope Multicast Addresses Block FF0X::TBD for the
878	   operation of the GAAP protocol.  The registry description field
879	   should indicate "GAAP".

891	   IANA will create two multicast address ranges for the GAAP protocol
892	   to allocate application-use addresses from.

913	           Registry Name: GAAP IPv4 Allocation Range
914	           Registration Procedure: IETF Review

916	           Registry Name: GAAP IPv6 Allocation Range
917	           Registration Procedure: IETF Review

The lead-in says assignments in existing registries; every sub-section
then says IANA "will create"; and lines 913-917 create two registries
with registration procedures. Three different kinds of action - creating
a registry, assigning a value, reserving a range - are conflated, and
IANA cannot act on "will create one UDP port number". Line 878's
singular "the registry description field" covers two different
registries.

The two registries are the clearest case: nothing registers anything in
them and nothing could, because GAAP addresses are derived at run time
rather than assigned. A registry with a registration procedure and no
possible registrant is not an IANA action.

(b) Section 9.3 contains one IPv6 allocation, described three
incompatible ways.

Section 9.3 requests two things, not three: one IPv4 range and one IPv6
range. Line 891 says two multicast address ranges; IPv4 follows at lines
892-893 and IPv6 at lines 903-907. The IPv6 one is then constrained
twice, in two paragraphs separated by the registry-creation lines,
neither adding a request the other does not:

907	   for IPv4.  This allocation MUST come from the Dynamic Multicast Group
908	   IDs registry defined in
909	   [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id], and publication of
910	   this document as an RFC is dependent on that registry existing; see
911	   the Normative References.

919	   For IPv6 multicast addresses, the GAAP application allocation range
920	   should be in the new "Dynamic Multicast Group IDs" registry requested
921	   by [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id].  This new registry
922	   requests the division of the 32-bit group ID range 0xA0000000 through
923	   0xAFFFFFFF.  The GAAP allocation range should come out of this 32-bit
924	   range.

What makes it read as more than one request is that the single
allocation is described three incompatible ways:

1) Line 154: "TBD2/32" - an IPv6 address prefix of length 32, fixing 32
   bits and leaving 96 to vary.

153	      address [RFC4291].  The application allocation range is TBD1/10
154	      for IPv4 and TBD2/32 for IPv6.

2) Lines 903-905: "a /32 block ... sized to match the 32-bit Group ID" -
   the same notation meaning the opposite: 96 bits fixed, 32 varying,
   that is, a /96.

3) Lines 922-924: a sub-range within 0xA0000000-0xAFFFFFFF - 28 bits
   wide, not 32, and called "this 32-bit range" in the same sentence.

Only (3) corresponds to anything the "Dynamic Multicast Group IDs"
registry could hold, and it is the reading that contradicts Section 6.1
(discuss-7). No width is ever actually requested.

(c) The IPv6 allocation cannot be made from that registry.

The referenced draft was published as RFC 10028 (Proposed Standard,
August 2026). Its IANA Considerations record that IANA has created the
"Dynamic Multicast Group IDs" registry in the "IPv6 Multicast Address
Space" registry group, and that the "Standards Action" registration
policy is required to update it. This document is Experimental, so IANA 
cannot make the assignment.

Separately, 0xA0000000-0xAFFFFFFF is not a division that RFC 10028 made.

(d) The IPv4 /10 has no available source block, and the size is left
unresolved.

892	   to allocate application-use addresses from.  For IPv4, a /10 block in
893	   a new registry range is requested.  The size follows from the hash-
894	   based allocation model in Section 6: a larger host portion within the
895	   block, combined with the up to 4 candidate addresses per group name
896	   (see "Acceptable Group Hash List" in Section 2), keeps collisions
897	   infrequent enough that a GAAP node rarely needs to fall back past its
898	   first candidate address.  As the draft has previously noted, because
899	   a /10 is nonetheless a large portion of the IPv4 multicast space,
900	   this size warrants specific attention from IETF and IANA before
901	   allocation, and the WG welcomes further discussion of the appropriate
902	   block size, including analysis of collision probability at expected
903	   deployment scales.

No source block is named, and RFC 5771 leaves none available. RFC 5771's
table accounts for 224.0.0.0/4 in full; everything is assigned or
RESERVED, and of the RESERVED space RFC 5771 states that "Applications
MUST NOT use addressing in the IANA reserved blocks." A /10 therefore
requires reclassifying part of a RESERVED block - an IETF action
updating BCP 51, not an IANA assignment.

RFC 5771 also addresses a request of this size directly: where a very
large number of addresses is required, the assignment is to be staged,
with later stages made only after the earlier ones are fully used. A /10
is 4,194,304 addresses in one step, for a protocol with no deployment.

The justification also carries no arithmetic, and the document concedes
the question is open. Lines 898-903 say the size warrants attention
before allocation and that the WG welcomes further discussion - in the
text of a document at IESG evaluation!

(e) The UDP port request is incomplete

858	   IANA will create one UDP port number for the GAAP protocol,
859	   registered per the Service Name and Transport Protocol Port Number
860	   Registry guidance in [RFC6335]:

866	   |gaap   |TBD   |udp      | GAAP Control |IESG    |IETF   |draft-   |
867	   |       |      |         | Packets      |        |Chair  |ietf-pim-|
868	   |       |      |         |              |        |       |gaap     |

The required RFC 6335 fields are present. Three gaps: the range is not
stated (System, User or Dynamic Ports, which have different procedures);
no justification is given, where RFC 6335 requires an explanation of why
Dynamic Ports are unsuitable and, for a System Port, why User Ports are
too; and the Reference column carries the draft name rather than
[RFCXXXX].

The ports expert has recorded an objection on the Datatracker,
recommending instead the multicast application port number assigned by
draft-ietf-intarea-multicast-application-port, on the grounds that
multicast services are already sufficiently differentiated by IP address
and so do not need their own port assignments. I concur with the expert.

GAAP is asking for two well-known multicast addresses of its
own in Section 9.2; once a receiver has joined the GAAP group, the
destination address identifies the traffic and the port adds no
demultiplexing. Section 4's firewall argument does not apply,
because the well-known group address is at least as good a filter key.
RFC 6335 treats ports as scarce and requiring justification, and a
permanent assignment to an experiment - while the IETF standardizes a
shared mechanism for exactly this case - is hard to justify.

(f) A BCP 14 keyword, and an implementation requirement, inside the IANA
section.

907	   for IPv4.  This allocation MUST come from the Dynamic Multicast Group
908	   IDs registry defined in

A BCP 14 keyword in IANA Considerations, where everything already reads
as MUST-level to IANA. The sentence is wrong on the substance per (c) in any
case.

884	   implementations MUST use an admin-local or organization-local IPv6
885	   scope (not link-local scope) when selecting the scope value X for the
886	   IPv6 address, so that control messages can be forwarded beyond a
887	   single link when the deployment requires it.

This is not an IANA instruction: it is a requirement on implementations
inside an address assignment request. It is normative protocol behaviour
and belongs in Section 4 or Section 6, where it would be reviewed as
specification. Same class as discuss-10.

Suggested way forward. Rewrite Section 9 so that each sub-section states
one action in a form IANA can execute, and so that nothing depends on a
request that cannot be granted.

- Correct the lead-in at lines 853-854 once the list below is settled.

- Delete lines 913-917.

- Section 9.1 (port). Preferred: withdraw the assignment request and
  state that the experiment uses a port number assigned by
  draft-ietf-intarea-multicast-application-port.

- Section 9.2 (control addresses). Restate as assignment requests -
  "IANA is requested to assign one IPv4 multicast address from the
  Internetwork Control Block (224.0.1.0/24) and one IPv6 multicast
  address ..."; line 876's "224.0.1.x" should read 224.0.1.0/24. Move
  lines 884-887 out per (f).

- Section 9.3, IPv6. Remove the allocation request. State that GAAP, as
  an Experimental protocol, uses group IDs from within the Experimental
  Use range 0xFE000000-0xFEFFFFFF assigned by [RFC10028] - which says
  that "The Experimental Use range may be used for experimentation with
  new dynamic allocation protocols" - and that no IANA action is
  required. Do not name a specific value or sub-range: the range is not
  assignable, GAAP is not its only possible user, and the sub-range in
  use must be coordinated among those running the experiment. State that
  coordination requirement, state how many group ID bits the chosen
  sub-range must leave free for the derivation (discuss-7), and name the
  transition to a permanent assignment as an exit criterion. Correct
  line 154 to match and drop the "/32 block" and "this 32-bit range"
  language per (b).

- Section 9.3, IPv4 - is a /10 needed at all? I am not sure if that is
  even wise for something experimental.

- Present each table as it will appear in the registry, with a reference
  column pointing at this document.

<discuss-9> IANA considerations without any registry for the protocol itself?

237	   At this time, there is a single message called the Claim message with
238	   type value 1.  Type value of 0 is reserved.

274	      Reserved:  MUST be set to zero by the sender and ignored by the
275	         receiver.

"At this time" states the expectation of further message types, yet
there is no registry for the remaining 14 values of the 4-bit Type
field, so a future document has no way to obtain one. 

The 20-bit Reserved field has the same gap, and the preferred fix for
discuss-4 needs to allocate a bit from it. Separately, Section 4 defines
discard behaviour for a bad Marker, a zero-length group name and a
Record Count mismatch, but not for an unrecognized Type.

Suggested new Section 9.4:

   IANA is requested to create the "GAAP Message Types" registry in a
   new "Group Address Allocation Protocol (GAAP)" registry group. The
   registration policy is IETF Review. Each entry contains a Value (a
   4-bit unsigned integer), a Name, and a Reference. The initial
   contents are:

      Value   Name          Reference
      0       Reserved      [RFCXXXX]
      1       Claim         [RFCXXXX]
      2-15    Unassigned

Please also add to Section 4: "A receiver that does not recognize the Type 
value MUST discard the message without further processing." If discuss-4 is 
fixed by a header flag, add a companion registry for the Reserved bits.

<discuss-10> Normative protocol behavior and implementation aspects in Operational
Considerations

Section 7

707	   GAAP implementations are expected to follow the UDP usage guidelines
708	   in [RFC8085].  A sender SHOULD keep a multi-record Claim message
709	   small enough to avoid IP fragmentation on the path, and SHOULD limit
710	   the total UDP payload of a Claim message to 1232 octets so that it
711	   fits within the 1280-octet IPv6 minimum MTU without fragmentation
712	   (this bounds the number of records per message well below the maximum
713	   Record Count of 255 when Group Names are long); the UDP checksum MUST
714	   be enabled and verified, and a receiver MUST validate the Marker and
715	   message length (the received UDP payload length as reported by the
716	   UDP header) before further processing a packet, discarding malformed
717	   packets as described in Section 4.  The periodic and jittered Claim
718	   timer described in Section 6 already bounds the sending rate of a
719	   well-behaved node; implementations SHOULD additionally rate-limit
720	   processing of received Claim messages per source to bound the cost of
721	   handling a misbehaving or malicious sender (see also Section 8).

727	   vector; implementations SHOULD nonetheless avoid generating a
728	   response larger than the triggering message.  GAAP Claim messages,
729	   whether for the well-known GAAP Group Address or for application
730	   group addresses, are intended for delivery within the scope implied
731	   by the multicast group address used (see Section 9) and
732	   implementations SHOULD set the IPv4 TTL or IPv6 Hop Limit
733	   consistently with that scope rather than defaulting to a large value.

Most of this is specification, not operational guidance. Sending and receiving 
rules belong in Section 4 or Section 6, where they would be read as requirements. 

Suggested moves: lines 713-717 (checksum, Marker and length validation,
malformed discard) into Section 4 beside the existing malformed-message
rules at lines 355-362; lines 708-713 (message sizing) into Section 4 as
a sending rule or into a new Section 6.5; lines 717-721 (receive rate
limiting) and 728-733 (TTL/Hop Limit) into Section 6. That leaves
Section 7 with deployment scope, coexistence, RP requirements and
monitoring guidance.

# IESG review of draft-ietf-pim-gaap-20

CC @MikeBishop

## Discuss

### Section 4, paragraph 10

Multiple "fields" in this section do not appear to describe actual
fields in the record. (Address Field Usage, Timestamp Comparison, Multi-Record
Parsing) The layout will be misleading in the extreme. This is perhaps
editorial, yet critical enough to interop that I believe it rises to DISCUSS
level.

### Section 5, paragraph 1
```
     The GAAP API has the following API calls a multicast application will
     use.  A multicast application imports the library before using it in
     its code logic.  This section documents a python library.  The
```
This is the specification of a protocol. The protocol is not a Python library,
and almost certainly does not have API calls. I strongly recommend removing the
API definition, or moving it to an appendix as an illustration of how one might
integrate this protocol. What I think you intend to show here is the protocol's
abstract data model -- the things that it needs from the layer above in order to
drive its own processes.

### Section 8, paragraph 3
```
     Deployments enabling encryption MUST use a mechanism that provides
     both confidentiality and integrity, such as an AEAD construction
     (e.g., ChaCha20-Poly1305); using ChaCha20 without a message
     authentication code is NOT RECOMMENDED, since the Marker functions
     only as a format check and not as an integrity check.
```
This is inconsistent in multiple ways.

First: Encryption is optional, but if you enable it, it MUST have certain
properties? How is encryption with only one of these properties worse than no
encryption?

Second: If you MUST have both properties, how is using something that provides
only one of them NOT RECOMMENDED (=> SHOULD NOT)? That's a mismatch of
requirement levels.

** Section 4 and 8.  These sections makes reference to the possibility of “encrypting GAAP messages”.  

-- Section 8, “The message Marker is always sent in cleartext as 0xAAAAAAAA (see Section 4) and is used by the receiver to identify the packet as GAAP before determining whether the following record data is encrypted.”  How is a determination make that “record data” is encrypted”?

-- Section 8, “Deployments choosing an encryption mechanism SHOULD prefer an Authenticated Encryption with Associated Data (AEAD) construction …”  How is an encryption scheme added to the GAP message?  There appears to be no way to add additional fields.  For example, where would an authentication tag go?

-- If GAAP messages are encrypted, how does the message format currently defined in Section 4 change?

-- How are basic keying activities handled if the GAAP protocol provides no means to identify keys?  I appreciate that they are defined as out of scope but is that realistic for anything but the most trivial deployment?

** Section 5.1-5.4 have “CODE” blocks and the text implies that there is a normative API.

-- Please provide a reference to the formal programming/specification language being used?

-- Which parts of this text are normative?

** Section 9.3
   For IPv6 multicast addresses, the GAAP application allocation range
   should be in the new "Dynamic Multicast Group IDs" registry requested
   by [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id].  This new registry
   requests the division of the 32-bit group ID range 0xA0000000 through
   0xAFFFFFFF.  The GAAP allocation range should come out of this 32-bit
   range.

I believe the registry in question is https://www.iana.org/assignments/ipv6-multicast-addresses#dynamic-multicast-group-ids and the guiding document is https://datatracker.ietf.org/doc/html/rfc10028.  This document is requesting allocation from a range (0x90000000-0xEFFFFFFF) whose registration policy is “Standards Action”.   As an experimental status document, this would not be permitted.  See Section 4.9 of RFC8126.