Group Address Allocation Protocol (GAAP)
draft-ietf-pim-gaap-23

[Ballot discuss]
** Section 4.  The “encrypted format” remains underspecified.  The text seems to imply that an encrypted payload replaces most of the fields depicted in Figure 1.  Unspecified is:

-- Exactly what fields are in the encrypted payload?  Everything after Type? Reserved?  The text seems to suggest the Marker would be encrypted.

-- What is the format of the encrypted payload?  Minimally, there has to be two pieces of information, the ciphertext and an authentication tag/MAC.  Are there other fields?  In what order are those fields?  What are the size of those fields?

-- How is the size of the encrypted payload determined?

** Section 9

(a) ChaCha20 [RFC8439] without a message authentication code has been
  used to encrypt GAAP messages. 

(b) Deployments choosing an encryption
  mechanism SHOULD prefer an Authenticated Encryption with Associated
  Data (AEAD) construction such as ChaCha20-Poly1305 [RFC8439], which
  additionally authenticates the message, over ChaCha20 alone. 
    …
(c) 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 a matching decrypted

This series of guidance appears to be internally inconsistent in multiple places

-- Sentence (c) opens with saying that confidentiality + integrity is mandatory (MUST), but then ends the sentence to say that a confidentiality-only approach (ChaCha20 with a MAC) is only NOT RECOMMENDED

-- Sentence (a) and (b) describes a configuration which violates the mandatory guidance of Sentence (c).

[Ballot comment]
Thank you to Meral Shirazipour for the GENART review.

Thanks for the revised text in -22 and -23.

** Section 9.  “confidentiality and integrity” is not necessarily the same as AEAD.  Why not mandate AEAD?

[Ballot comment]
Thanks to Tim H. for the excellent SECDIR review and the authors for incorporating most of that feedback into the Security Considerations section already.

I believe the DISCUSSes already present cover my potential feedback.  I would like to additionally state that Deb's comments about how cryptography is used here should be considered and likely incorporated before final publication.

I would like to VERY much thank you for the experiment section describing what the experiment under consideration here is.  It is much appreciated to have that clearly described.

[Ballot comment]
Thank you for the work put into this document. I think the concept helpful, but possibly needs further consideration of collisions. I see this new protocol in a space where previous attempts have failed to deploy an automated multicast address assignment method. I note this is proposed for the experimental track.

# COMMENTS (non-blocking)

## Both ASM and SSM addresses can be allocated.
Somewhere a little deeper in the document it explains how ASM and SSM are relevant. I suspect many people using multicast will have a question at the very start as to the mode of multicast address that can be allocated. Can this be explained in the abstract or the introductory paragraph?

I saw this text later: "Applications using GAAP-allocated addresses will typically also rely on ASM delivery for their own traffic, though an application with a single known source could in principle use PIM-SSM for its own data plane once its address has been allocated and claimed via GAAP."

## How is encryption going to be introduced?
I would like to understand the format for encrypted and non-encrypted use. The method in the present text does not explain how an experiment could include both of these uses. I see this question is in support of Roman's DISCUSS ballot.

## Port Request and Usage
In section 4, I see a request for a port assignment. I wonder if more use could be made of the unique port in this protocol that handles addresses: This is not a request to hack the protocol, but the only reason I could think of to allocate a new port would be if an experimenter wished to sent some of these messages to the group-destination-address to which the messages relate? I could see merit in such approach, since that would ease some important scaling to support very large groups - since the only nodes that are involved in a conflict are the ones using the same group-destination-address.

## API definitions
Please consider placing the API definition in a non-normative appendix, since these definition appear to be OS-specific.

## Message Extension?
The specification does not have a version field, so how will a PS be deployed if there is a format change? I see it does include a Type Value indicating the message. This appears to suggest the need for a registry to provide extensibility, and allow possible new formats following an experiment!

## Firewalls allowing GAAP (security consideration)
The text states: "GAAP can work behind firewall devices as long as the GAAP destination port is permitted through filters." Multicast traffic can also be filtered based on the group-destination-address, so I expected this to also say that this address also needed to be permitted.

## Firewalls depending on GAAP (operational consideration)
Since GAAP dynamically allocates a group destination address, this has implications for firewall rules that filter on the group-destination-address, and might suggest that future firewalls could track the GAAP protocol to impose an appropriate filter policy?

## Monitoring depending on GAAP (operational consideration)
It would seem useful to note that since GAAP dynamically allocates a group destination address, the allocation may be useful to track when monitoring or troubleshooting the operation of a protocol that depends on GAAP.

## Does a GAAP sender set DF in IPv4?
"A sender MUST NOT send a Claim message whose total UDP payload exceeds 1232 octets, so that it fits within the 1280-octet IPv6 minimum MTU without fragmentation, accounting for typical IPv6/UDP header overhead."
- This I understand, but then I ask what happens for a sender in IPv4. I expect the fixed size will not often be a problem, but does the sender set DF? or allow fragmentation?

[Ballot comment]
I support the DISCUSS ballots of Andy, Éric, Mike, and Roman. These cover everything I would consider DISCUSS worthy on an Experimental RFC.

Thank you to Sheng Jiang for the intdir review on -14. Unfortunately, I see that some of this feedback is still outstanding, which I won't raise to a DISCUSS on an Experimental, but still wish to note as I firmly believe it would make this a better RFC. From Sheng Jiang's review, two points:

(1) I appreciate the added detail since -14 on the rationale for 32-bit time fields, but I remain unconvinced that this is an appropriate approach versus just using 64 bits given the heuristic nature of the current approach. Nevertheless, an experiment may prove this overkill.

(2) I completely agree that there should be a type indicator and a single field for the IP address. Having two address fields when only one can be valid seems ripe for later abuse/hackiness to convey some other meaning with a second address, not to mention a (very minor) waste of space (that could be used to extend the timestamp perhaps!).

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

Thanks to Mike for working through all my concerns and addressing them.

There remains only a minor thing about deleting section 10.3 from IANA Cons as it has no actions for IANA anymore.

[Ballot comment]
Thanks to Tim Hollebeek for their secdir review.

I support the discusses of Roman, and Mike Bishop - I will not be repeating them here.  I am making my comments 'no objection', but I think they are important for the authors to address.  Having a specification which is more complete allows for a better experiment.

Section 2, Acceptable Group Hash List:  I confess that I don't understand why 4 versions of a group name are necessary.  Is it to give the ability to reuse Group Names 4 times?  Do you really need that?  It adds complexity, for what value?

Section 4, Timestamp comparison:  All of this timestamp comparison seems to add quite a bit of complexity.  Of course encrypting this part of the message would eliminate some of this (i.e. it would be harder to spoof).  It would at least reduce the attack space to an entity 'in the club'.

Section 9:  This section could stand some reorganization, it seems to jump around a bit.  Perhaps paragraphs on these topics:  encrypt or not, marker signaling, crypt requirements (confidentiality, integrity,  ChaCha w/ or w/out Poly1305), provisioning shared keys w/ re-key, nonce construction, keyed GAAP node behaving badly even when encryption is used.  If the authors were to do this, I think contradictions/duplications will be found.  It would also quantify what exactly is in scope and out of scope - important for an implementer to understand.

Section 9, para 1: no mti encryption mechanism:  However, only ChaCha/Poly1305 is listed.  If it is the intention to allow other encryption options, then one might need some language to that effect. 

Section 9, para 3 and 4:  Why not MUST - When is it acceptable to use a non-AEAD construction?  Currently this is a SHOULD (or in para 4 NOT RECOMMENDED). I would expect something like 'if encrypting, then MUST use AEAD'. [or see my last comment]

Section 9, para 4:  Nonce reuse leads to catastrophic failures for many AEAD ciphers (including ChaCha/Poly).  Depending on how widely the keys are shared, and how big the space is, guaranteeing reuse is nearly impossible.  Typically, there are ways to ensure that each entity with a shared key has a portion of the 'nonce space' - using counters and splitting up the counter space are only a couple options.  The other option is to require shared keys to be only pairwise, even then one has to split up the nonce space (counter). (See Section 4 of RFC 8439).

Section 9, para 4:  There are other ways of providing both confidentiality and integrity than using an AEAD cipher.  Some of this depends on the threat model of the data being protected (which is not in the draft from what I can see).  Sometimes, encrypting a CRC or other integrity check value is enough of an integrity check, and is much simpler to implement (with fewer pitfalls - nonce).

IANA understands that two major changes have been made to this document (which is being marked "IANA OK"):

1) Section 9.3 ("GAAP Multicast Group Allocation Ranges") is no longer requesting assignments from IANA.

2) A new Section 9.4 is creating a registry called "GAAP Message Types" in a new registry group called "Group Address Allocation Protocol (GAAP)." The registration procedure will be IETF Review, and the registry will be initialized with the contents of Table 3.

[Ballot discuss]
** 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.

[Ballot comment]
Thank you to Meral Shirazipour for the GENART review.

** Section 9.3
  As the draft has previously noted, because
  a /10 is nonetheless a large portion of the IPv4 multicast space,
  this size warrants specific attention from IETF and IANA before
  allocation, and the WG welcomes further discussion of the appropriate
  block size, including analysis of collision probability at expected
  deployment scales.

Thanks for raising this issue.  I have the same concern especially since this document has experiment status.  What is the scale that motivates the /10?

[Ballot discuss]
# 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.

[Ballot comment]
## Comments

I support Andy's, Eric's, and Ketan's DISCUSS positions.

### Section 1, paragraph 1
```
    that it can run within a library a multicast application compiles
    into its executable binary.
```
Surely the method of compilation is irrelevant to the protocol? I'd stop at
saying it's lightweight, so it's feasible even in constrained environments.

### Section 3, paragraph 6
```
    *  The GAAP node waits one periodic Claim interval (see Section 6,
        roughly 1 minute) after sending its initial Claim message.  If no
```
This surprised me. In network terms, one minute seems like an eternity to
determine whether a particular address is usable. With retries, it may be as
long as four minutes before an error is returned. I'd have expected at least a
faster timer and probing all four candidates in ~parallel before selecting one.

### Section 4, paragraph 0
```
    addresses GAAP allocates for applications.  The Claim message is sent
    in a UDP checksummed packet where the source port is ephemeral and
    chosen by the sender and the destination port is a well-known port
```
If the source port is chosen by the sender, why does it need to be ephemeral? Is
there any technical reason for that, or does it just work out that way in a
given implementation?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 1, paragraph 3
```
-    the past, they include SAP [RFC2974], SDP [RFC4566], mDNS [RFC6762],
-            ^
+    the past; they include SAP [RFC2974], SDP [RFC4566], mDNS [RFC6762],
+            ^
```

### Section 1, paragraph 1
```
    GAAP is a possible solution to the issues described in problem
    statement [RFC10019].
```
Either add "the" (before "problem statement") or just drop "problem statement"
and point to the RFC.

### Section 2, paragraph 1

Thanks for a thorough Terminology section. These are half-way between
embedded in a sentence ("Group Name is...") and a definition list ("Group Name:
An ASCII string..."). Consider dropping the "is" and going fully to the
definition list.

### Section 4, paragraph 1
```
    type value 1.  Type value of 0 is reserved.  Claim messages are sent
```
Drop the "of" for consistency with the previous sentence.

### Outdated references

Document references `draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id`, but that
has been published as `RFC10028`.

Document references `draft-ietf-pim-zeroconf-mcast-addr-alloc-ps`, but that has
been published as `RFC10019`.

Reference `[RFC4566]` to `RFC4566`, which was obsoleted by `RFC8866` (this may
be on purpose).

### Grammar/style

#### Section 5.1, paragraph 4 and Section 5.4, paragraph 2
```
never outside it. The following pseudo-code illustrates the functionality, w
                                ^^^^^^^^^^^
```
```
solve a collision, the following pseudo-code will illustrate how 3 more attem
                                ^^^^^^^^^^^
```
This word is normally spelled as one.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
# Andy Newton, ART AD, comments for draft-ietf-pim-gaap-20
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pim-gaap-20.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Thanks to the Reviewers

Thanks to Murray Kucherawy for the ARTART review.

## Discuss

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/,
a DISCUSS ballot is just a request to have a discussion on the following topics.

All of my DISCUSSes come from Murray Kucherawy's ARTART review, and I
did not seem them addressed so I am raising this DISCUSS.

### Type Value

The Claim message type of 0 is reserved and 1 is defined in this document.
The type appears to be a 4-bit value. Are the other types reserved?
Is there suppose to be an IANA registry for them?

237        At this time, there is a single message called the Claim message with
238        type value 1.  Type value of 0 is reserved.  Claim messages are sent
239        to the GAAP Group Address (see Section 2), a well-known multicast
240        address allocated by IANA (see Section 9), distinct from the
241        addresses GAAP allocates for applications.  The Claim message is sent
242        in a UDP checksummed packet where the source port is ephemeral and
243        chosen by the sender and the destination port is a well-known port
244        allocated by IANA.  GAAP can work behind NAT and firewall devices as
245        long as the GAAP destination port is permitted through filters.

247          0                  1                  2                  3
248          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
249        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
250        |Type=1 |              Reserved                | Record Count  |
251        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
252        |                      0xAAAAAAAA Marker                      |
253        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
254        |                  IPv4 Multicast Group Address                | \
255        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  \
256        |                                                              |    R
257        |                        IPv6 Multicast                        |    e
258        |                        Group Address                        |    c
259        |                                                              |    o
260        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    r
261        |                          Timestamp                            |    d
262        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  /
263        |                          Group Name ...                      |  /
264        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
265        |                            ...                              |/
266        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

### MUST in IANA Considerations 1

This block in the IANA considerations section contains BCP14 language.

See the IESG statement on BCP14 language:
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

In this case, the normative language are instructions to implementers
and not to IANA, so this statement should go in a place in the doc that
is more likely to be read by implementers.

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".  GAAP control messages sent to these
880        addresses are intended to reach all GAAP nodes within an
881        administrative domain rather than being confined to a single link;
882        consistent with that, the IPv4 address comes from the Internetwork
883        Control Block rather than the Local Network Control Block, and
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.

### MUST in IANA Considerations 2

It is unclear to me to whom this MUST applies. Does it apply to IANA?
Does it apply to the RFC Editor? Regardless, it should not be in the IANA
considerations section.

891        IANA will create two multicast address ranges for the GAAP protocol
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.  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 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.

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

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

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.

[Ballot discuss]

# É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.

[Ballot discuss]

# É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 Tony Li 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.

[Ballot comment]

## COMMENTS (non-blocking)

### Ketan's DISCUSS

I support most of Ketan DISCUSS issues, notably using TBD1 / TBD2 for the mcast groups through the text.

### Section 4

Suggest to move the time comparison specification outside of the field description. The BCP14 SHOULD must have guidance about when they can be bypassed or what are the consequences of bypassing them.

### Section 6.1

Strongly suggest to use either lower-case or upper-case of the group name.

Please use elements for the pseudo code.

I wonder the usefulness of `low_bits = hash & 0xffffffff` as it is further masked with `(low_bits & GAAP_V[46]_MASK)`.

Python will complain about `if (collision == False): return(group_address)` indentation ;-)

### Section 6.3

Just wondering what happens if the 2 partioned networks used a "+1" for one and "+2" for the other... Will this be detected as well and will everyone converge ?

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

[Ballot comment]
Hi Dino and Mike,

Thank you for the effort put into this document.

Also, thanks to Bo Wu for the OPSDIR review and the authors for engaging and taking care of that review.

# I have already reviewed an early version of this document. The authors kindly addressed the comments raised then in in -13: https://mailarchive.ietf.org/arch/msg/mboned/Suc5biakiQUe64Y9CMkEbYAGt4k/.

# The simulation details shared with mboned are useful to help assess the requested prefix size: https://mailarchive.ietf.org/arch/msg/mboned/GFmpLiVlE_UJZP6my0HuAuY8AXQ/.

# The terminology section incudes normative behavior that I think is better consolidated in the main spec. Likewise, I don't think the use of normative language in the overview section is adequate here.

# Encrypted/Unencrypted traffic

As the same port number is used, maybe consider a more deterministic approach for disambiguating both (distinct markers, for example).

# On Timestamp

Please double check that you are following the recommendation in Section 3 of RFC8877.

# Name Delimiter

The current approach relies on the terminating null to identify a name. I wonder whether using a more explicit approach (that is, encode the name length) would be better.

# Grouping Claims vs. individual claim

Is there any guidance that can be provided to include multiple records vs sending claims with a single record?

# There is a risk that under some conditions (massive reboots, power outage, etc.) that an avalanche of Claim messages are sent by hosts. Maybe add a mention how the design protext against such overload.

# Internal implementation details

The description includes details that are internal to an implementation. I wonder whether this is really needed in the spec. An example of such details is:

CURRENT:
  A multicast application imports the library before using it in
  its code logic.

# Follow RFC5952 recommendations for representing IPv6 addresses. For example, use the lower-case in this part:

CURRENT:
  IANA will create one multicast address from the IPv4 Internetwork
  Control Block 224.0.1.x [RFC5771] and one multicast address from the
  IPv6 Variable Scope Multicast Addresses Block FF0X::TBD for the
  operation of the GAAP protocol 

# Please make sure the IANA allocation (TBD1/TBD2) cited in the main doc are also called as such in the IANA considerations.

Cheers,
Med

[Ballot discuss]
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  tag at the end to ensure you
are seeing the full review.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

[Ballot comment]
Following are some comments on this document:


136 2.  Definition of Terms

"GAAP node", the term  in almost every normative sentence in
Section 6, is not included. Please add it, and say whether it is a host,
a process or a library instance - Section 6.4's rule about multiple local
applications sharing a group name depends on it.


170       "acceptable" for a group name.  They are calculated using the
171       SHA-256 hash function on 1 of 4 character strings: "",
172       "+1", "+2", or "+3".

504           for append in ["+1", "+2", "+3"]:
505               hash = sha256(group_name + append)

A group name is "an ASCII string" with no excluded characters,
so "my-audio-group+1" is a legal group name and its first candidate is the
same hash input, and so the same address, as the second candidate of
"my-audio-group".

Suggested replacement for the Acceptable Group Hash List definition:

  There are 4 hashed values regarded as "acceptable" for a group name.
  Each is computed by hashing a single octet, whose value is 0, 1, 2 or
  3, followed immediately by the octets of the group name. The octet
  value 0 gives the first candidate address, 1 the second, and so on.
  These 4 hashes are the only candidate group addresses a GAAP node
  will ever try for a given group name; a GAAP node MUST NOT run the
  hash on any other input for this group name.

The Section 6.1 pseudocode needs the same change. This also answers the
question of the terminating null raised in my DISCUSS on the derivation,
since the input becomes an octet sequence rather than a string.

213   *  The GAAP node waits one periodic Claim interval (see Section 6,
214       roughly 1 minute) after sending its initial Claim message.  If no
215       colliding Claim message is received from another GAAP node within
216       that window, the application can start using the group address.

536   name, group address, and timestamp.  If the group address collides
537   with other GAAP nodes already using the address, one of the nodes
538   will send a Claim message to notify the colliding node that it needs
539   to allocate a new group address.

555   multi-record Claim message.  The periodic Claim message is sent by
556   setting a periodic timer to a random value in the range 60 to 66
557   seconds (a base of 1 minute, plus jitter of 0 to 10% of 1 minute).

The claimant waits roughly 60 seconds; the defender's timer runs
60 to 66 seconds. An immediate triggered response is defined only for
the same-name-different-hash case at lines 570-576; for an ordinary
collision, lines 537-539 give no timing at all. So the defender's next
Claim can be up to 66 seconds away and the claimant starts using a
colliding address. Widening the wait to 66 seconds does not fix it - if
the defender was itself suppressed by a third party the delay is
unbounded, and per my first DISCUSS point it may be suppressed by the
claimant's own message.

Suggested addition, requiring an immediate triggered Claim on receipt of
a colliding Claim, damped as in the next comment:

  On receiving a Claim message carrying a group address it is currently
  claiming with a different group name, a GAAP node MUST send a Claim
  message for that group address after a random delay uniformly
  distributed in [0, 1] second, rather than waiting for its periodic
  timer, unless it receives an equivalent Claim from another node
  during that delay, in which case it suppresses its own.

The claimant's wait would then be stated as a small multiple of that
bound rather than as "one periodic Claim interval".

223   *  Claim messages are sent periodically.  They are sent by a single
224       node using a delay-timer suppression mechanism similar to IGMP
225       [RFC1112].  See Section 6 for details.

RFC 1112 specifies IGMPv1. Report suppression is IGMPv2, RFC 2236;
IGMPv3, RFC 3376, removed it. Please cite the right specification. (The
missing random delay is a separate comment below.)

242   in a UDP checksummed packet where the source port is ephemeral and
243   chosen by the sender and the destination port is a well-known port
244   allocated by IANA.  GAAP can work behind NAT and firewall devices as
245   long as the GAAP destination port is permitted through filters.

The firewall half of this is fine. Claim messages go to a
multicast destination address, and IPv4 NAT does not translate or
forward multicast in any standard way, so the NAT half states a property
NAT does not have and attaches a condition that has nothing to do with
NAT. If any translation is on the path, two mechanisms break silently:
the source address breaks collision tie-breaking and it keys the bad-actor
list in Section 8.

s/NAT and firewall devices/firewall devices

If something specific about NAT is meant, please state the topology and
what happens to the source-address-dependent mechanisms across it.

250     |Type=1 |              Reserved                | Record Count  |

Type is 4 bits, Reserved 20 and Record Count 8. None of those
widths appears in the field descriptions at lines 272-291, only in the
figure, which is not guaranteed to render or to be accessible. Please state
the width in each field description.

318       Timestamp comparison:  Timestamps are compared using serial number
319         arithmetic [RFC1982] so that a single wraparound of the 32-bit
320         counter (in the year 2106) does not by itself cause incorrect
321         ordering.

Section 3.2 of RFC 1982 notes that there are pairs of values s1
and s2 that are not equal but where neither is greater nor less than the
other. With SERIAL_BITS = 32 that is a difference of exactly 2^31, and
it is reachable: an unset clock reads 0, and 2^31 seconds after the
epoch is 2038-01-19, so from 2038 the comparison against a correct clock
is first undefined and then inverted.

Suggested addition: "If two Timestamps are neither less than nor greater
than one another under [RFC1982] comparison, they are treated as equal
for the purposes of collision arbitration and the source-address
tie-break applies." It is also worth stating that a Timestamp of 0 is
treated as an unset clock and always loses the tie-break.

325         source address wins the collision.  GAAP nodes are not required
326         to have synchronized clocks, but SHOULD use a monotonic or NTP-
327         disciplined source for the Timestamp where available.  A

"Where available" makes this self-satisfying: nothing on the
wire distinguishes compliance from non-compliance, and no consequence is
stated. Please lowercase it, or restate: "GAAP nodes are not required to
have synchronized clocks. Where a monotonic or NTP-disciplined clock
source is available, it is preferable to use it for the Timestamp." The
substantive protection against a bad clock is the timestamp skew point
in my DISCUSS.

570   way to know a prior collision occurred.  Any one existing node
571   already using a later hash in the list for that group name responds
572   with its own Claim message, sent immediately rather than waiting for
573   its periodic timer, carrying the group address it is already using
574   and its (earlier) Timestamp; if more than one existing node responds,
575   the new node processes the first valid response it receives and MAY
576   discard duplicates.

581   If the triggered Claim is lost in transit, the new node continues to
582   periodically re-claim the first hash; the existing node will observe
583   the unsuppressed Claim on its own next periodic timer expiry (or
584   trigger again immediately on receipt of the new node's repeated
585   Claim) and retransmit its response, so the state converges without a
586   bound on the number of retries.

Every node claiming that name responds at once; "if more than
one existing node responds" acknowledges the implosion without preventing it.
IGMP report suppression, cited as the model, works because responders wait a
random delay and cancel on hearing another's report - GAAP has the cancellation
without the delay, so at the moment it matters every responder transmits.

Please add the random response delay and suppression per the previous
comment, and state a maximum triggered-Claim rate per group address per
node - one per second, for example.

574   and its (earlier) Timestamp; if more than one existing node responds,
575   the new node processes the first valid response it receives and MAY
576   discard duplicates.  On receiving that triggered Claim, the new GAAP
577   node MUST yield, since the existing node's Timestamp is earlier, and
578   switch to using the same group address the existing node is claiming
579   rather than allocating a new one; the new node's own Claim for the
580   first hash is then withdrawn implicitly by no longer being refreshed.

"MUST yield, since the existing node's Timestamp is earlier"
assumes the conclusion. Clocks are explicitly not synchronized (lines
325-327), so a new node whose clock is behind carries the earlier
Timestamp, and the document does not say what happens then. Both nodes
believe they won, and because the two addresses differ this is not a
collision under the document's own definition, so nothing ever resolves
it: the group name is permanently split across two addresses. The
two-partitions-converge reasoning at lines 520-524 does not cover this,
since it addresses same-name-same-address.

Suggested way to specify convergence without reference to clocks, since
for one group name there is no correctness reason to prefer either
address:

  For a given group name, a GAAP node that receives a Claim message
  carrying that group name with a group address appearing earlier in
  the Acceptable Group Hash List than the address it is itself claiming
  continues to claim its own address and MUST send a triggered Claim. A
  node that receives a Claim carrying its group name with an address
  appearing later in the list MUST yield and switch to that address.
  Timestamps are not used for this comparison.

625   GAAP is published as Experimental because decentralized hash-based
626   multicast group address allocation has not been deployed.  The
627   experiment aims to determine whether the collision detection and
628   resolution mechanisms defined in this document are sufficient for
629   practical deployments and what collision rates occur in networks of
630   varying scale.  The experiment is considered complete when
631   operational experience demonstrates the protocol is suitable for
632   Standards Track or when fundamental limitations are identified that
633   require a revision.

This paragraph in Operational Considerations, is the only
description of the experiment anywhere. Neither the Abstract  nor the
Introduction says the protocol specified is Experimental. And it is the
wrong section: why GAAP is Experimental, what the experiment is and when it
ends are statements about the document's status, not operational guidance
for a deployment.

Suggestion:

1) State the status in the Abstract and the Introduction - one sentence
  each: the Abstract that the document defines an experimental
  protocol, the Introduction why, pointing at the new section below.

2) Move the experiment discussion out of Operational Considerations into
  its own section with a title that says what it is - "Rationale for
  Experimental Status", or similar. Lines 625-633 move there, with the
  scalability material at lines 734-739 that is really about what the
  experiment should find out. I leave it to the authors to add anything
  further.

Also worth considering: a narrower first experiment confined to a single
link or subnet would exercise the derivation, collision detection and
suppression - where every open question is - without ASM/RP
infrastructure, without a /10, and without the inter-domain scope
questions. That addresses with my DISCUSS on the intended scope.

657   GAAP is expected to operate within a single administrative domain and
658   this document does not define behavior for GAAP Claim messages
659   crossing administrative domain boundaries.

If GAAP operates within one administrative domain and defines no
cross-domain behaviour, its addresses need not be globally unique or
globally scoped. RFC 2365 already reserves 239.0.0.0/10, 239.64.0.0/10
and 239.128.0.0/10 as unassigned and available for expansion of the
Organization Local Scope - the requested unit exactly - and RFC 5771
records that the Administratively Scoped Block needs no IANA assignment
policy. That consumes no globally scoped space and needs no
reclassification of an RFC 5771 RESERVED block, which is the obstacle
the /10 request currently hits.

I may be missing how the WG weighed this.

So, should the IPv4 allocation come from within 239.0.0.0/8 given lines
657-659, and if not, what deployment requires globally scoped GAAP
addresses? The authors and the WG will need to decide this.

722   Because GAAP messages are small requests that do not trigger a
723   disproportionately large response, and Claim messages are sent to a
724   multicast group rather than reflected to a spoofed unicast target,
725   GAAP is not expected to be useful as a reflection or amplification
726   vector; implementations SHOULD nonetheless avoid generating a
727   response larger than the triggering message.

The preceding clauses establish that GAAP generates no
disproportionate response. A triggered Claim carries whatever records
the responder is claiming, which is unrelated to the size of the message
that triggered it, so no implementation action can either comply with or
violate this. Please drop the clause, or restate it as design intent
without a keyword.


777   An open-source GAAP implementation exists where ChaCha20 [RFC7539] is
778   used to encrypt GAAP messages.

782   implementation's key management procedure is a simple shared key that
783   is configured with the application.

Two security-relevant claims about a specific implementation -
that it uses ChaCha20, and that its key management is a configured
shared key - with no reference or URL, so neither is verifiable. The
shepherd writeup meanwhile relies on this, recording that there is an
open source implementation referenced in the document as satisfying the
implementation question; the document references nothing.

Please do not refer to an implementation that is not identified. The
substantive point can be made without attributing it:

  ChaCha20 [RFC8439] without a message authentication code has been
  used to encrypt GAAP messages. Deployments choosing an encryption
  mechanism SHOULD prefer an Authenticated Encryption with Associated
  Data (AEAD) construction such as ChaCha20-Poly1305 [RFC8439], which
  additionally authenticates the message, over ChaCha20 alone. Where a
  shared key is configured with the application, key management is a
  deployment responsibility; see below.

If the authors want to describe an implementation, that belongs in an
implementation report - not as an unattributed claim inside Security
Considerations.

785   Deployments enabling encryption MUST use a mechanism that provides
786   both confidentiality and integrity, such as an AEAD construction
787   (e.g., ChaCha20-Poly1305); using ChaCha20 without a message
788   authentication code is NOT RECOMMENDED, since the Marker functions
789   only as a format check and not as an integrity check.

Please move [RFC8439] to the normative references.

819   *  Even when an encrypted channel is used, a bad actor could be
820       claiming a group address not derived from one of the group name
821       inputs used for the Acceptable Group Hash List (see Definition of
822       Terms section).  Cooperating nodes should ignore such messages and
823       not try to send Claim messages to correct the bad actor node.
824       Note that a bad actor can spoof the source address of another
825       node's Claim message, so source-address based mitigations are
826       best-effort.  Implementations SHOULD bound the size of the bad-
827       actor list and treat entries as advisory hints rather than
828       authoritative state, since source addresses in Claim messages can
829       be spoofed.

831   *  A bad actor could send an invalid timestamp giving it tie-breaking
832       priority when a group address collision occurs.  If the group
833       address has been prior claimed by another node with a timestamp
834       earlier than the invalid timestamp, cooperating nodes should put
835       the bad actor node on a bad-actor list and ignore future messages
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.

845   *  A bad actor could send messages too often and is not adhering to
846       the random delay or periodic timer procedures in this document.
847       When this occurs, cooperating nodes should start ignoring messages
848       from the bad actor node and not reset or cancel timers, or send
849       triggered Claim messages

These bad-actor-list bullets specify what a node does on receiving
certain messages - protocol behaviour, written with lowercase "should" -
inside Security Considerations. That content should move to Section 6 with
the threat rationale left in Section 8, or be stated plainly as advice rather
than as behaviour.


930   [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id]
931               Karstens, N., Farinacci, D., and M. McBride, "Updates to
932               Dynamic IPv6 Multicast Address Group IDs", Work in
933               Progress, Internet-Draft, draft-ietf-pim-updt-ipv6-dyn-
934               mcast-addr-grp-id-13, 10 March 2026,
935               .

This has been published as RFC 10028 - this requires some other text
updates that reference it.

1038   [RFC7539]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
1039               Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
1040               .

1042   [RFC8439]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
1043               Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
1044               .

RFC 7539 is obsoleted by RFC 8439. RFC 8439 defines ChaCha20 as well as
ChaCha20-Poly1305, so the single citation at line 777 can simply move?

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pim-gaap-18. If any part of this review is inaccurate, please let us know.

We understand that, upon approval of this document, there are three actions which we must complete.

IANA understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document:

[I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id]

First, in the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

A single new udp port will be registered as follows:

Name: gaap
Port Number: [ TBD-at-Registration ]
Transport Protocol: udp
Description: GAAP Control Packets
Assignee: IESG
Contact: IETF Chair
Reference: [ RFC-to-be ]

IANA will assign a port number for gaap. An expert review has been requested for the port request. The IANA state for the document will be set to "IANA NOT OK" until the port review is completed.

Second, IANA will create one multicast address from the IPv4 Internetwork Control Block (224.0.1.0 - 224.0.1.255 (224.0.1/24)) registry in the IPv4 Multicast Address Space registry group located at:

https://www.iana.org/assignments/multicast-addresses/

and one multicast address from the Variable Scope Multicast Addresses registry in the IPv6 Multicast Address Space registry group located at:

https://www.iana.org/assignments/ipv6-multicast-addresses/

As this requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document’s IANA state can be changed to “IANA OK.”

Third, IANA will create two multicast address ranges for the GAAP protocol to allocate application-use addresses from. For IPv4, a /10 block in a new registry range is requested.

In addition, a /32 block in a new registry range is being requested, sized to match the 32-bit Group ID used directly in the hash-based derivation in Section 6; the larger IPv6 multicast address space makes collision probability far less of a concern than for IPv4. This allocation MUST come from the Dynamic Multicast Group IDs registry defined in [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id] and publication of this document as an RFC is dependent on that registry existing; see the Normative References.

In both of these cases, IANA will consult with an Expert Reviewer for these two requests. We will initiate the required Expert Review via a separate request. This review must be completed before the document’s IANA state can be changed to “IANA OK.”

We understand that these three actions are the only ones required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

Request for IETF Last Call review by TSVART Completed: Ready with Nits. Reviewer: Tommy Pauly. Sent review to list. Submission of review completed at an earlier date.

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.

The following Last Call announcement was sent out (ends 2026-08-03):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pim-gaap@ietf.org, gunter@vandevelde.cc, pim-chairs@ietf.org, pim@ietf.org, stig@venaas.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Group Address Allocation Protocol (GAAP)) to Experimental RFC


The IESG has received a request from the Protocols for IP Multicast WG (pim)
to consider the following document: - 'Group Address Allocation Protocol
(GAAP)'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-08-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a design for a lightweight decentralized
  multicast group address allocation protocol (named GAAP and
  pronounced "gap" as in "mind the gap").  The base allocation protocol
  requires no centralized service and minimal configuration, although
  deployments using encryption or administrative scoping may require
  configuration.  The protocol runs among group participants which need
  a unique group address to send and receive multicast packets.
  Tailored for IPv4 and IPv6 networks, this design offers a simple,
  lightweight option rather than extending an existing protocol.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pim-gaap/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
More than a few, but majority of WG fairly silent. But I believe majority thinks
it is useful.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is an open source implementation referenced in the document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This would be used by multicast applications. So would be good to get review from
art, and also int area.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

It is ready, except for some very minor nits mentioned below in 14 and 20.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

I've gone through these for art, int and rtg areas. No issues that I can see,
but the document should be reviewed by those areas.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Experimental. This is currently an experiment. It has some text explaining this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, no IPR.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Code fragments should be tagged. Most are, but some are missed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All are free,

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Main issue here is that the document requests allocations of big blocks
(a /10 for IPv4, a /32 group-ID block for IPv6) that needs to be done by IETF,
and not a regular IANA allocation.

The IANA considerations have a few lines about registry name and procedure
that I don't think should be there.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new registries as I understand it, despite the comments about name and
procedure. I think this is just left over from an earlier version.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
More than a few, but majority of WG fairly silent. But I believe majority thinks
it is useful.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is an open source implementation referenced in the document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This would be used by multicast applications. So would be good to get review from
art, and also int area.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

It is ready, except for some very minor nits mentioned below in 14 and 20.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

I've gone through these for art, int and rtg areas. No issues that I can see,
but the document should be reviewed by those areas.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Experimental. This is currently an experiment. It has some text explaining this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, no IPR.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Code fragments should be tagged. Most are, but some are missed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All are free,

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Main issue here is that the document requests allocations of big blocks
(a /10 for IPv4, a /32 group-ID block for IPv6) that needs to be done by IETF,
and not a regular IANA allocation.

The IANA considerations have a few lines about registry name and procedure
that I don't think should be there.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new registries as I understand it, despite the comments about name and
procedure. I think this is just left over from an earlier version.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
More than a few, but majority of WG fairly silent. But I believe most majority thinks it is useful.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is an open source implementation referenced in the document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This would be used by multicast applications. So would be good to get review from applications people. And also int area.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

It is ready, but there are a couple of minor nits as mentioned below.

It needs some text about what the experiment is etc.
draft-bonica-gendispatch-exp-07

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

I've gone through these for art, int and rtg areas. No issues that I can see,
but the document should be reviewed by those areas.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Experimental. This is currently an experiment.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, no IPR.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Code fragments should be tagged.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All are free,

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Main issue here is that the document requests allocations of big blocks
(a /10 for IPv4, a /32 group-ID block for IPv6) that needs to be done by IETF,
and not a regular IANA allocation.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Mostly clear. TBD.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/