[pim] Re: [Shepherding AD review] review of draft-ietf-p im-gaap-17

--===============5799601605528147001==
Content-Type: multipart/alternative; boundary="000000000000ac87f20655c1a6b9"

--000000000000ac87f20655c1a6b9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Gunter,

Thank you for the extensive comments. Very helpful. We have incorporated
all of your comments in the just submitted -18. See you in Vienna.

mike

On Mon, Jun 29, 2026 at 11:46=E2=80=AFPM Gunter van de Velde (Nokia) <
[email protected]> wrote:

> Hi authors,
>
> Many thanks to Stig Venaas for the Shepherd write-up, Sheng Jiang for the
> INTDIR review and Zhang (Sandy) Zheng for the RTGDIR review.
>
> I reviewed draft-ietf-pim-gaap-17. Thank you for the continued work on
> this document. I have a series of major and minor observations that I thi=
nk
> needs to be looked at before starting further processing and considering
> initiating a IETF LC.
>
> Major Observations
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> 1. IPv4 group address derivation does not match the requested GAAP
> allocation range
>
> Section 6.1 derives an IPv4 multicast address as follows:
>
> group_address =3D 0xe0000000 | (low_bits & 0x007fffff)
>
> This produces addresses in 224.0.0.0 through 224.127.255.255, i.e., it
> uses only the low-order 23 bits under the 224/8 prefix. That does not
> appear to match Section 9.3, which requests an IPv4 /10 block for GAAP
> allocation.
>
> A /10 means that the first 10 bits are fixed, the remaining 22 bits are
> available for assigning multicast addresses.
> But the algorithm is using 23 variable bits. Those do not seem to natch?
>
> So if IANA gives you a /10 block, the algorithm should generate addresses
> only inside that /10 block.
>
> This is also problematic because it can produce addresses from ranges tha=
t
> are already reserved or assigned for other purposes, including
> 224.0.0.0/24 and 224.0.1.0/24. Please align the pseudocode with the
> actual IANA-allocated GAAP IPv4 range and ensure that GAAP allocation nev=
er
> generates addresses outside that range.
>
> The current pseudocode derives addresses from a much broader range than
> the one requested from IANA. As a result, it can generate multicast
> addresses that are already reserved or assigned for other purposes (for
> example, within 224.0.0.0/24 or 224.0.1.0/24). This risks collisions with
> existing multicast protocol assignments and incorrect forwarding behavior=
.
> The address derivation algorithm should be constrained so that it can onl=
y
> generate addresses within the GAAP-specific block allocated by IANA.
>
> This may require a construction of the form:
> group_address =3D GAAP_V4_BASE | (low_bits & GAAP_V4_MASK)
> where GAAP_V4_BASE and GAAP_V4_MASK are derived from the actual allocated
> range.
>
> 2. IPv4 collision model mixes 32-bit uniqueness and 23-bit Ethernet mappi=
ng
>
> Section 2 says that achieving unique 32 bits allows Layer-2 switches to
> avoid multicast MAC address collisions. The text then correctly notes tha=
t
> IPv4 multicast maps only the low-order 23 bits.
>
> For IPv4, unique 32-bit multicast addresses are not sufficient to avoid
> Ethernet multicast MAC aliasing; only the mapped low-order 23 bits matter=
.
> Please clarify the collision model and whether GAAP is trying to avoid:
>
> * only network-layer group-address collisions;
> * Layer-2 multicast MAC collisions for IPv4;
> * Layer-2 multicast MAC collisions for IPv6;
> * or all of the above.
>
> If Layer-2 collision avoidance is part of the protocol objective, the IPv=
4
> and IPv6 rules need to be stated separately and supported by the address
> derivation algorithm.
>
> 3. Encryption/security mechanism is not sufficiently specified for
> interoperability
>
> Section 8 says GAAP should run over an encrypted multicast channel and
> says that all implementations should support the same encryption mechanis=
m
> and key management procedure. It also mentions an implementation using
> ChaCha20, but the draft does not define an interoperable encryption profi=
le.
>
> The document needs to be clearer about whether encryption is:
>
> * mandatory to implement,
> * mandatory to use,
> * optional but recommended,
> * or entirely out of scope.
>
> If the document expects interoperable encryption, it needs to specify the
> complete wire behavior, including algorithm, nonce/IV construction,
> authentication/integrity protection, replay considerations, key identifie=
r
> if any, and how the receiver distinguishes plaintext from ciphertext.
> ChaCha20 alone provides confidentiality but not authentication; an AEAD
> construction such as ChaCha20-Poly1305 would normally be expected.
>
> If encryption is out of scope, then the text should not say that all GAAP
> implementations should support the same encryption mechanism, because the
> document does not define one.
>
> 4. Missing and outdated security reference
>
> Section 8 cites RFC7539, but RFC7539 is not listed as normative
> references, only informative. Also, RFC7539 has been obsoleted by RFC8439=
.
> Please add the appropriate reference and consider using RFC8439 instead.
>
> If encryption remains only an example implementation detail, the referenc=
e
> can likely be informative. If the draft defines an interoperable encrypti=
on
> mode, the reference should be normative.
>
> 5. Dependency on the IPv6 dynamic multicast Group ID update draft
>
> Section 9.3 says that the GAAP IPv6 allocation should come from the new
> Dynamic Multicast Group IDs registry defined by
> draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id.
>
> That makes the GAAP IANA action dependent on that document. The current
> reference is informative, but the dependency appears normative for the IA=
NA
> allocation. Please either:
>
> * make draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id a normative
> reference and ensure the publication dependency is tracked, or
> * rewrite the IANA request so it does not depend on a registry that is no=
t
> yet created.
>
> 6. UDP usage guidance is missing
>
> GAAP defines a UDP-based protocol with multicast periodic messages,
> triggered messages, suppression, variable-length records, possible
> multi-record packets, and use across NAT/firewall devices. I expected a
> reference to RFC8085 and some discussion of UDP usage considerations.
>
> Please address at least:
>
> * maximum message size and fragmentation avoidance;
> * behavior when many records are included in a Claim message;
> * rate limiting and congestion considerations;
> * checksum requirements;
> * packet validation before processing;
> * amplification/reflection considerations;
> * multicast scope and hop-limit/TTL expectations.
>
> COMMENTS
> =3D=3D=3D=3D=3D=3D=3D=3D
>
> General reference review
>
> 1. Missing references that should probably be added
>
> Please consider adding references to:
>
> * RFC8085 for UDP usage guidelines;
> * RFC6335 and/or RFC7605 for service-name and port-number registration
> guidance;
> * RFC5771 for IPv4 multicast address allocation guidance;
> * RFC8439 if ChaCha20 or ChaCha20-Poly1305 remains in the text;
> * an Ethernet multicast mapping reference if Layer-2 multicast collision
> avoidance remains a protocol objective.
>
> 2. Normative/informative classification issues
>
> RFC8536 is currently normative, but it does not seem like the right
> reference for a =E2=80=9C32-bit standard epoch UTC timestamp in seconds.=
=E2=80=9D RFC8536
> specifies the Time Zone Information Format, not a general protocol
> timestamp format. Please either remove this reference, replace it with a
> more appropriate timestamp reference, or define the timestamp directly as
> seconds since 1970-01-01T00:00:00Z.
>
> draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id appears to need to be
> normative if the IANA allocation depends on the registry it creates.
>
> General section review
>
> 1. Abstract
>
> The abstract says GAAP requires no configuration setup and no centralized
> services. Section 8 later discusses shared-key configuration and key
> management. Please qualify the =E2=80=9Cno configuration setup=E2=80=9D s=
tatement, for
> example:
>
> The base allocation protocol requires no centralized service and minimal
> configuration, although deployments using encryption or administrative
> scoping may require configuration.
>
> 2. Section 1 =E2=80=94 Introduction
>
> The text says other approaches require =E2=80=9Cglobal scope adding laten=
cy,
> configuration, use of a single subnet, and are not decentralized.=E2=80=
=9D That
> sentence seems too broad for the list of protocols cited. Please soften o=
r
> split the statement so it is clear which limitation applies to which prio=
r
> mechanism.
>
> 3. Section 2 =E2=80=94 Definition of Terms
>
> The =E2=80=9CGroup Address=E2=80=9D definition says =E2=80=9Ca non-link-l=
ocal IPv4 multicast group
> address=E2=80=9D. IPv4 multicast does not normally use the term =E2=80=9C=
link-local=E2=80=9D in the
> same way IPv6 does. Consider saying =E2=80=9Cnot from the Local Network C=
ontrol
> Block unless explicitly assigned for GAAP protocol operation=E2=80=9D or =
otherwise
> align with RFC5771 terminology.
>
> The =E2=80=9CGAAP Group Address=E2=80=9D definition says this address mus=
t not come from
> the GAAP multicast address block allocated by IANA. Please clarify the
> distinction between:
>
> * the GAAP protocol multicast address used for GAAP control messages; and
> * the GAAP allocation range used to derive application multicast groups.
>
> The =E2=80=9CAcceptable Group Hash List=E2=80=9D definition says there ar=
e four acceptable
> hash values using "", "+1", "+2", and "+3". Later Section 6.1 says =E2=80=
=9C3 more
> attempts=E2=80=9D. Please clarify whether the maximum number of candidate=
 addresses
> is exactly four and what happens when all four collide.
>
> 4. Section 3 =E2=80=94 Overview of Protocol Operation
>
> The text says if no Claim message is sent in response, the application ca=
n
> start using the group address. Please specify the wait interval and wheth=
er
> multiple probes are required before using the address. Without a defined
> claim/response window, two nodes starting at nearly the same time may bot=
h
> conclude that no conflict exists.
>
> The text says a Claim message is =E2=80=9Creturned=E2=80=9D when a collis=
ion occurs. Since
> this is multicast-based, =E2=80=9Creturned=E2=80=9D may be misleading. Co=
nsider =E2=80=9Csent in
> response=E2=80=9D or =E2=80=9Ctriggered=E2=80=9D.
>
> 5. Section 4 =E2=80=94 GAAP Message Format
>
> The packet format has Type, Reserved, Record Count, Marker, and then
> records, but the record format does not include an explicit group-name
> length. The text says the length is determined from the overall message
> length minus fixed fields. That works for a single record, but it is
> ambiguous for multiple records because each variable-length group name is
> null-terminated and records may not be aligned.
>
> Please explicitly define record parsing for multi-record messages,
> including:
>
> * how a receiver finds the next record;
> * whether a zero-length group name is valid;
> * whether duplicate records in one message are allowed;
> * maximum group-name length;
> * maximum Record Count;
> * malformed-message handling when Record Count exceeds what the packet ca=
n
> contain.
>
> The Marker is after Record Count. If the packet is encrypted, it is not
> clear which fields remain in cleartext and which are encrypted. Please
> specify this if encryption remains part of the protocol.
>
> The =E2=80=9CReserved=E2=80=9D field says set to 0 and ignored on receipt=
. Usually the
> receiver should ignore it unless future extensibility requires validation=
.
> If the intent is future use, =E2=80=9CMUST be set to zero by the sender a=
nd ignored
> by the receiver=E2=80=9D is fine.
>
> 6. Section 4 =E2=80=94 Timestamp
>
> The timestamp is 32-bit seconds and is used for relative ordering. A
> 32-bit seconds counter wraps. The text says wraparound does not materiall=
y
> impact correctness if comparisons are done appropriately, but does not
> define the comparison.
>
> Please define the comparison rule, especially for:
>
> * wraparound;
> * equal timestamps;
> * unsynchronized clocks;
> * clocks set in the future;
> * clocks set before boot or reset.
>
> There should be a deterministic tie-breaker for equal timestamps,
> otherwise two colliding nodes could both believe they won or both believe
> they lost.
>
> 7. Section 5 =E2=80=94 GAAP API
>
> This section documents a Python API, but the rest of the document defines
> a protocol. Please clarify whether Section 5 is normative or illustrative=
.
>
> If illustrative, consider saying:
>
> "The following API is illustrative and shows one possible application
> interface. Implementations are free to expose different programming
> interfaces."
>
> 8. Section 6.1 =E2=80=94 Allocating Group Addresses
>
> As noted in the above major observation, the IPv4 pseudocode must be
> aligned with the actual IANA-allocated GAAP IPv4 range.
>
> For IPv6, the pseudocode uses:
>
> group_address =3D 0xff0e...0000 | low_bits
>
> Please define the full IPv6 address format precisely. In particular,
> specify the flags, scope, and group ID placement. The =E2=80=9C...=E2=80=
=9D notation is not
> sufficient for an implementable wire specification.
>
> 9. Section 6.1 =E2=80=94 Collision resolution
>
> The text says there are three more attempts after the initial hash, for a
> total of four possible addresses. Please specify what the API returns and
> what protocol behavior occurs when all four candidate addresses collide.
>
> Also, if the same group name always maps to the same four addresses, two
> independent partitions using the same group name should converge to the
> same address after repair. Please clarify whether a collision for the sam=
e
> group name is intentionally not a collision even if timestamps differ.
>
> 10. Section 6.2 =E2=80=94 Claiming Group Addresses
>
> The timer text says =E2=80=9C1 minute plus a jitter value=E2=80=9D and th=
en says =E2=80=9Ca random
> number in a 10% range of 1 minute (60 to 66 seconds).=E2=80=9D This is co=
nfusing.
> If the timer is 1 minute plus jitter, then the range would be 60 to 66
> seconds only if the jitter is 0 to 6 seconds. Please rewrite.
>
> The suppression mechanism says receivers reset their timer when they
> receive a Claim message. Please clarify whether suppression is per group
> name, per group address, per node, or global. A global timer could suppre=
ss
> unrelated group claims incorrectly.
>
> The text says a new GAAP node may send a Claim for the first group hash
> and previous nodes will trigger sending a Claim for one of the other
> addresses. Please make the state machine more precise. In particular:
>
> * when does an existing node respond;
> * which address does it claim;
> * how does the new node know it must switch;
> * what happens if multiple existing nodes respond;
> * what happens if the triggered claim is lost.
>
> 11. Section 6.3 =E2=80=94 Partition Repair
>
> The partition-repair behavior depends on timestamps. Please add a
> tie-breaker for equal timestamps and guidance for badly skewed clocks.
>
> Also, the text says applications start using the new address, meaning
> senders source using the new group address and receivers leave/join.
> Multicast senders do not usually =E2=80=9Csource using the group address=
=E2=80=9D; they
> send to the group address. Please reword to avoid confusion with source
> addresses.
>
> 12. Section 6.4 =E2=80=94 Releasing Group Addresses
>
> Please define whether release is purely local or whether a release
> indication is sent. The current text says the protocol stops claiming the
> group address, but does not send a release message. That is acceptable, b=
ut
> should be explicit.
>
> Also clarify what happens if one local application releases a group
> address while another local application still uses the same group
> name/address.
>
> 13. Section 7 =E2=80=94 Operational Considerations
>
> The text says applications are required to keep group names unique. This
> seems to undercut GAAP=E2=80=99s purpose of deriving group addresses from=
 shared
> group names. Please clarify the intended uniqueness domain:
>
> * unique across unrelated applications;
> * shared by participants in the same application/session;
> * administratively unique within a deployment;
> * or globally unique.
>
> The section recommends observing active claims and clearing state, but th=
e
> protocol is described as stateless. Please clarify what state is expected
> or optional.
>
> 14. Section 8 =E2=80=94 Security Considerations
>
> Please avoid relying only on encryption as a mitigation. GAAP also needs
> validation rules for claims, rate limiting, replay handling, and bad-acto=
r
> behavior.
>
> The bad-actor list idea needs more care. A malicious node could spoof
> another node=E2=80=99s source address and cause receivers to suppress or =
ignore
> valid participants. If bad-actor listing remains, describe how spoofing i=
s
> prevented or make the mechanism local/heuristic.
>
> The text says a bad actor with an invalid timestamp should be ignored if
> the timestamp is earlier than the current time. This seems backwards or a=
t
> least unclear. Please define what makes a timestamp invalid and how clock
> skew is tolerated.
>
> 15. Section 9.1 =E2=80=94 UDP Port Number
>
> Please align the request with the Service Name and Transport Protocol Por=
t
> Number Registry template and guidance. The table should provide a complet=
e
> service-name request, including service name, transport protocol,
> description, reference, and assignment contact/controller as required by
> IANA practice.
>
> 16. Section 9.2 =E2=80=94 GAAP Protocol Multicast Addresses
>
> The request for one IPv4 multicast address from 224.0.1.x should cite the
> IPv4 multicast address assignment guidance. Please also specify whether
> GAAP control packets are intended to be routed beyond the local subnet, a=
nd
> if not, whether 224.0.1.x is the correct block.
>
> For IPv6, =E2=80=9CFF0X::TBD=E2=80=9D needs clearer scope guidance. Which=
 scopes are valid
> for GAAP control messages? Is GAAP intended for link-local,
> site-local/admin-local, organization-local, or global scope? Please speci=
fy
> how an implementation chooses the scope.
>
> 17. Section 9.3 =E2=80=94 GAAP Multicast Group Allocation Ranges
>
> The IPv4 /10 request is very large and the draft already notes that
> discussion with IETF and IANA is needed. Please provide stronger
> justification for the size, expected utilization, collision probability,
> and why existing allocation mechanisms or scoped ranges are insufficient.
>
> For IPv6, please resolve the dependency on the Dynamic Multicast Group ID=
s
> registry draft as noted above.
>
> 18. Appendix B =E2=80=94 Change Log
>
> The change log is useful during draft development but is usually removed
> before RFC publication. Please remove it before publication, or add a not=
e
> to remove it or confirm with the RFC Editor if the WG wants to retain it.
>
> Best regards,
> Gunter Van de Velde
> Routing Area Director

--000000000000ac87f20655c1a6b9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Gunter,</div><div><br></div><div>Thank you for the=
 extensive comments. Very helpful. We have incorporated all of your comment=
s in the just submitted -18. See you in Vienna.</div><div><br></div><div>mi=
ke</div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"lt=
r" class=3D"gmail_attr">On Mon, Jun 29, 2026 at 11:46=E2=80=AFPM Gunter van=
 de Velde (Nokia) &lt;<a href=3D"mailto:[email protected]">gunt=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">Hi authors,<br>
<br>
Many thanks to Stig Venaas for the Shepherd write-up, Sheng Jiang for the I=
NTDIR review and Zhang (Sandy) Zheng for the RTGDIR review.<br>
<br>
I reviewed draft-ietf-pim-gaap-17. Thank you for the continued work on this=
 document. I have a series of major and minor observations that I think nee=
ds to be looked at before starting further processing and considering initi=
ating a IETF LC.<br>
<br>
Major Observations<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
1. IPv4 group address derivation does not match the requested GAAP allocati=
on range<br>
<br>
Section 6.1 derives an IPv4 multicast address as follows:<br>
<br>
group_address =3D 0xe0000000 | (low_bits &amp; 0x007fffff)<br>
<br>
This produces addresses in 224.0.0.0 through 224.127.255.255, i.e., it uses=
 only the low-order 23 bits under the 224/8 prefix. That does not appear to=
 match Section 9.3, which requests an IPv4 /10 block for GAAP allocation.<b=
r>
<br>
A /10 means that the first 10 bits are fixed, the remaining 22 bits are ava=
ilable for assigning multicast addresses.<br>
But the algorithm is using 23 variable bits. Those do not seem to natch?<br=
>
<br>
So if IANA gives you a /10 block, the algorithm should generate addresses o=
nly inside that /10 block.<br>
<br>
This is also problematic because it can produce addresses from ranges that =
are already reserved or assigned for other purposes, including <a href=3D"h=
ttp://224.0.0.0/24" rel=3D"noreferrer" target=3D"_blank">224.0.0.0/24</a> a=
nd <a href=3D"http://224.0.1.0/24" rel=3D"noreferrer" target=3D"_blank">224=
.0.1.0/24</a>. Please align the pseudocode with the actual IANA-allocated G=
AAP IPv4 range and ensure that GAAP allocation never generates addresses ou=
tside that range.<br>
<br>
The current pseudocode derives addresses from a much broader range than the=
 one requested from IANA. As a result, it can generate multicast addresses =
that are already reserved or assigned for other purposes (for example, with=
in <a href=3D"http://224.0.0.0/24" rel=3D"noreferrer" target=3D"_blank">224=
.0.0.0/24</a> or <a href=3D"http://224.0.1.0/24" rel=3D"noreferrer" target=
=3D"_blank">224.0.1.0/24</a>). This risks collisions with existing multicas=
t protocol assignments and incorrect forwarding behavior. The address deriv=
ation algorithm should be constrained so that it can only generate addresse=
s within the GAAP-specific block allocated by IANA.<br>
<br>
This may require a construction of the form:<br>
group_address =3D GAAP_V4_BASE | (low_bits &amp; GAAP_V4_MASK)<br>
where GAAP_V4_BASE and GAAP_V4_MASK are derived from the actual allocated r=
ange.<br>
<br>
2. IPv4 collision model mixes 32-bit uniqueness and 23-bit Ethernet mapping=
<br>
<br>
Section 2 says that achieving unique 32 bits allows Layer-2 switches to avo=
id multicast MAC address collisions. The text then correctly notes that IPv=
4 multicast maps only the low-order 23 bits.<br>
<br>
For IPv4, unique 32-bit multicast addresses are not sufficient to avoid Eth=
ernet multicast MAC aliasing; only the mapped low-order 23 bits matter. Ple=
ase clarify the collision model and whether GAAP is trying to avoid:<br>
<br>
* only network-layer group-address collisions;<br>
* Layer-2 multicast MAC collisions for IPv4;<br>
* Layer-2 multicast MAC collisions for IPv6;<br>
* or all of the above.<br>
<br>
If Layer-2 collision avoidance is part of the protocol objective, the IPv4 =
and IPv6 rules need to be stated separately and supported by the address de=
rivation algorithm.<br>
<br>
3. Encryption/security mechanism is not sufficiently specified for interope=
rability<br>
<br>
Section 8 says GAAP should run over an encrypted multicast channel and says=
 that all implementations should support the same encryption mechanism and =
key management procedure. It also mentions an implementation using ChaCha20=
, but the draft does not define an interoperable encryption profile.<br>
<br>
The document needs to be clearer about whether encryption is:<br>
<br>
* mandatory to implement,<br>
* mandatory to use,<br>
* optional but recommended,<br>
* or entirely out of scope.<br>
<br>
If the document expects interoperable encryption, it needs to specify the c=
omplete wire behavior, including algorithm, nonce/IV construction, authenti=
cation/integrity protection, replay considerations, key identifier if any, =
and how the receiver distinguishes plaintext from ciphertext. ChaCha20 alon=
e provides confidentiality but not authentication; an AEAD construction suc=
h as ChaCha20-Poly1305 would normally be expected.<br>
<br>
If encryption is out of scope, then the text should not say that all GAAP i=
mplementations should support the same encryption mechanism, because the do=
cument does not define one.<br>
<br>
4. Missing and outdated security reference<br>
<br>
Section 8 cites RFC7539, but RFC7539 is not listed as normative references,=
 only informative. Also, RFC7539 has been obsoleted by RFC8439. Please add =
the appropriate reference and consider using RFC8439 instead.<br>
<br>
If encryption remains only an example implementation detail, the reference =
can likely be informative. If the draft defines an interoperable encryption=
 mode, the reference should be normative.<br>
<br>
5. Dependency on the IPv6 dynamic multicast Group ID update draft<br>
<br>
Section 9.3 says that the GAAP IPv6 allocation should come from the new Dyn=
amic Multicast Group IDs registry defined by draft-ietf-pim-updt-ipv6-dyn-m=
cast-addr-grp-id.<br>
<br>
That makes the GAAP IANA action dependent on that document. The current ref=
erence is informative, but the dependency appears normative for the IANA al=
location. Please either:<br>
<br>
* make draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id a normative reference=
 and ensure the publication dependency is tracked, or<br>
* rewrite the IANA request so it does not depend on a registry that is not =
yet created.<br>
<br>
6. UDP usage guidance is missing<br>
<br>
GAAP defines a UDP-based protocol with multicast periodic messages, trigger=
ed messages, suppression, variable-length records, possible multi-record pa=
ckets, and use across NAT/firewall devices. I expected a reference to RFC80=
85 and some discussion of UDP usage considerations.<br>
<br>
Please address at least:<br>
<br>
* maximum message size and fragmentation avoidance;<br>
* behavior when many records are included in a Claim message;<br>
* rate limiting and congestion considerations;<br>
* checksum requirements;<br>
* packet validation before processing;<br>
* amplification/reflection considerations;<br>
* multicast scope and hop-limit/TTL expectations.<br>
<br>
COMMENTS<br>
=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
General reference review<br>
<br>
1. Missing references that should probably be added<br>
<br>
Please consider adding references to:<br>
<br>
* RFC8085 for UDP usage guidelines;<br>
* RFC6335 and/or RFC7605 for service-name and port-number registration guid=
ance;<br>
* RFC5771 for IPv4 multicast address allocation guidance;<br>
* RFC8439 if ChaCha20 or ChaCha20-Poly1305 remains in the text;<br>
* an Ethernet multicast mapping reference if Layer-2 multicast collision av=
oidance remains a protocol objective.<br>
<br>
2. Normative/informative classification issues<br>
<br>
RFC8536 is currently normative, but it does not seem like the right referen=
ce for a =E2=80=9C32-bit standard epoch UTC timestamp in seconds.=E2=80=9D =
RFC8536 specifies the Time Zone Information Format, not a general protocol =
timestamp format. Please either remove this reference, replace it with a mo=
re appropriate timestamp reference, or define the timestamp directly as sec=
onds since 1970-01-01T00:00:00Z.<br>
<br>
draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id appears to need to be normat=
ive if the IANA allocation depends on the registry it creates.<br>
<br>
General section review<br>
<br>
1. Abstract<br>
<br>
The abstract says GAAP requires no configuration setup and no centralized s=
ervices. Section 8 later discusses shared-key configuration and key managem=
ent. Please qualify the =E2=80=9Cno configuration setup=E2=80=9D statement,=
 for example:<br>
<br>
The base allocation protocol requires no centralized service and minimal co=
nfiguration, although deployments using encryption or administrative scopin=
g may require configuration.<br>
<br>
2. Section 1 =E2=80=94 Introduction<br>
<br>
The text says other approaches require =E2=80=9Cglobal scope adding latency=
, configuration, use of a single subnet, and are not decentralized.=E2=80=
=9D That sentence seems too broad for the list of protocols cited. Please s=
often or split the statement so it is clear which limitation applies to whi=
ch prior mechanism.<br>
<br>
3. Section 2 =E2=80=94 Definition of Terms<br>
<br>
The =E2=80=9CGroup Address=E2=80=9D definition says =E2=80=9Ca non-link-loc=
al IPv4 multicast group address=E2=80=9D. IPv4 multicast does not normally =
use the term =E2=80=9Clink-local=E2=80=9D in the same way IPv6 does. Consid=
er saying =E2=80=9Cnot from the Local Network Control Block unless explicit=
ly assigned for GAAP protocol operation=E2=80=9D or otherwise align with RF=
C5771 terminology.<br>
<br>
The =E2=80=9CGAAP Group Address=E2=80=9D definition says this address must =
not come from the GAAP multicast address block allocated by IANA. Please cl=
arify the distinction between:<br>
<br>
* the GAAP protocol multicast address used for GAAP control messages; and<b=
r>
* the GAAP allocation range used to derive application multicast groups.<br=
>
<br>
The =E2=80=9CAcceptable Group Hash List=E2=80=9D definition says there are =
four acceptable hash values using &quot;&quot;, &quot;+1&quot;, &quot;+2&qu=
ot;, and &quot;+3&quot;. Later Section 6.1 says =E2=80=9C3 more attempts=E2=
=80=9D. Please clarify whether the maximum number of candidate addresses is=
 exactly four and what happens when all four collide.<br>
<br>
4. Section 3 =E2=80=94 Overview of Protocol Operation<br>
<br>
The text says if no Claim message is sent in response, the application can =
start using the group address. Please specify the wait interval and whether=
 multiple probes are required before using the address. Without a defined c=
laim/response window, two nodes starting at nearly the same time may both c=
onclude that no conflict exists.<br>
<br>
The text says a Claim message is =E2=80=9Creturned=E2=80=9D when a collisio=
n occurs. Since this is multicast-based, =E2=80=9Creturned=E2=80=9D may be =
misleading. Consider =E2=80=9Csent in response=E2=80=9D or =E2=80=9Ctrigger=
ed=E2=80=9D.<br>
<br>
5. Section 4 =E2=80=94 GAAP Message Format<br>
<br>
The packet format has Type, Reserved, Record Count, Marker, and then record=
s, but the record format does not include an explicit group-name length. Th=
e text says the length is determined from the overall message length minus =
fixed fields. That works for a single record, but it is ambiguous for multi=
ple records because each variable-length group name is null-terminated and =
records may not be aligned.<br>
<br>
Please explicitly define record parsing for multi-record messages, includin=
g:<br>
<br>
* how a receiver finds the next record;<br>
* whether a zero-length group name is valid;<br>
* whether duplicate records in one message are allowed;<br>
* maximum group-name length;<br>
* maximum Record Count;<br>
* malformed-message handling when Record Count exceeds what the packet can =
contain.<br>
<br>
The Marker is after Record Count. If the packet is encrypted, it is not cle=
ar which fields remain in cleartext and which are encrypted. Please specify=
 this if encryption remains part of the protocol.<br>
<br>
The =E2=80=9CReserved=E2=80=9D field says set to 0 and ignored on receipt. =
Usually the receiver should ignore it unless future extensibility requires =
validation. If the intent is future use, =E2=80=9CMUST be set to zero by th=
e sender and ignored by the receiver=E2=80=9D is fine.<br>
<br>
6. Section 4 =E2=80=94 Timestamp<br>
<br>
The timestamp is 32-bit seconds and is used for relative ordering. A 32-bit=
 seconds counter wraps. The text says wraparound does not materially impact=
 correctness if comparisons are done appropriately, but does not define the=
 comparison.<br>
<br>
Please define the comparison rule, especially for:<br>
<br>
* wraparound;<br>
* equal timestamps;<br>
* unsynchronized clocks;<br>
* clocks set in the future;<br>
* clocks set before boot or reset.<br>
<br>
There should be a deterministic tie-breaker for equal timestamps, otherwise=
 two colliding nodes could both believe they won or both believe they lost.=
<br>
<br>
7. Section 5 =E2=80=94 GAAP API<br>
<br>
This section documents a Python API, but the rest of the document defines a=
 protocol. Please clarify whether Section 5 is normative or illustrative.<b=
r>
<br>
If illustrative, consider saying:<br>
<br>
&quot;The following API is illustrative and shows one possible application =
interface. Implementations are free to expose different programming interfa=
ces.&quot;<br>
<br>
8. Section 6.1 =E2=80=94 Allocating Group Addresses<br>
<br>
As noted in the above major observation, the IPv4 pseudocode must be aligne=
d with the actual IANA-allocated GAAP IPv4 range.<br>
<br>
For IPv6, the pseudocode uses:<br>
<br>
group_address =3D 0xff0e...0000 | low_bits<br>
<br>
Please define the full IPv6 address format precisely. In particular, specif=
y the flags, scope, and group ID placement. The =E2=80=9C...=E2=80=9D notat=
ion is not sufficient for an implementable wire specification.<br>
<br>
9. Section 6.1 =E2=80=94 Collision resolution<br>
<br>
The text says there are three more attempts after the initial hash, for a t=
otal of four possible addresses. Please specify what the API returns and wh=
at protocol behavior occurs when all four candidate addresses collide.<br>
<br>
Also, if the same group name always maps to the same four addresses, two in=
dependent partitions using the same group name should converge to the same =
address after repair. Please clarify whether a collision for the same group=
 name is intentionally not a collision even if timestamps differ.<br>
<br>
10. Section 6.2 =E2=80=94 Claiming Group Addresses<br>
<br>
The timer text says =E2=80=9C1 minute plus a jitter value=E2=80=9D and then=
 says =E2=80=9Ca random number in a 10% range of 1 minute (60 to 66 seconds=
).=E2=80=9D This is confusing. If the timer is 1 minute plus jitter, then t=
he range would be 60 to 66 seconds only if the jitter is 0 to 6 seconds. Pl=
ease rewrite.<br>
<br>
The suppression mechanism says receivers reset their timer when they receiv=
e a Claim message. Please clarify whether suppression is per group name, pe=
r group address, per node, or global. A global timer could suppress unrelat=
ed group claims incorrectly.<br>
<br>
The text says a new GAAP node may send a Claim for the first group hash and=
 previous nodes will trigger sending a Claim for one of the other addresses=
. Please make the state machine more precise. In particular:<br>
<br>
* when does an existing node respond;<br>
* which address does it claim;<br>
* how does the new node know it must switch;<br>
* what happens if multiple existing nodes respond;<br>
* what happens if the triggered claim is lost.<br>
<br>
11. Section 6.3 =E2=80=94 Partition Repair<br>
<br>
The partition-repair behavior depends on timestamps. Please add a tie-break=
er for equal timestamps and guidance for badly skewed clocks.<br>
<br>
Also, the text says applications start using the new address, meaning sende=
rs source using the new group address and receivers leave/join. Multicast s=
enders do not usually =E2=80=9Csource using the group address=E2=80=9D; the=
y send to the group address. Please reword to avoid confusion with source a=
ddresses.<br>
<br>
12. Section 6.4 =E2=80=94 Releasing Group Addresses<br>
<br>
Please define whether release is purely local or whether a release indicati=
on is sent. The current text says the protocol stops claiming the group add=
ress, but does not send a release message. That is acceptable, but should b=
e explicit.<br>
<br>
Also clarify what happens if one local application releases a group address=
 while another local application still uses the same group name/address.<br=
>
<br>
13. Section 7 =E2=80=94 Operational Considerations<br>
<br>
The text says applications are required to keep group names unique. This se=
ems to undercut GAAP=E2=80=99s purpose of deriving group addresses from sha=
red group names. Please clarify the intended uniqueness domain:<br>
<br>
* unique across unrelated applications;<br>
* shared by participants in the same application/session;<br>
* administratively unique within a deployment;<br>
* or globally unique.<br>
<br>
The section recommends observing active claims and clearing state, but the =
protocol is described as stateless. Please clarify what state is expected o=
r optional.<br>
<br>
14. Section 8 =E2=80=94 Security Considerations<br>
<br>
Please avoid relying only on encryption as a mitigation. GAAP also needs va=
lidation rules for claims, rate limiting, replay handling, and bad-actor be=
havior.<br>
<br>
The bad-actor list idea needs more care. A malicious node could spoof anoth=
er node=E2=80=99s source address and cause receivers to suppress or ignore =
valid participants. If bad-actor listing remains, describe how spoofing is =
prevented or make the mechanism local/heuristic.<br>
<br>
The text says a bad actor with an invalid timestamp should be ignored if th=
e timestamp is earlier than the current time. This seems backwards or at le=
ast unclear. Please define what makes a timestamp invalid and how clock ske=
w is tolerated.<br>
<br>
15. Section 9.1 =E2=80=94 UDP Port Number<br>
<br>
Please align the request with the Service Name and Transport Protocol Port =
Number Registry template and guidance. The table should provide a complete =
service-name request, including service name, transport protocol, descripti=
on, reference, and assignment contact/controller as required by IANA practi=
ce.<br>
<br>
16. Section 9.2 =E2=80=94 GAAP Protocol Multicast Addresses<br>
<br>
The request for one IPv4 multicast address from 224.0.1.x should cite the I=
Pv4 multicast address assignment guidance. Please also specify whether GAAP=
 control packets are intended to be routed beyond the local subnet, and if =
not, whether 224.0.1.x is the correct block.<br>
<br>
For IPv6, =E2=80=9CFF0X::TBD=E2=80=9D needs clearer scope guidance. Which s=
copes are valid for GAAP control messages? Is GAAP intended for link-local,=
 site-local/admin-local, organization-local, or global scope? Please specif=
y how an implementation chooses the scope.<br>
<br>
17. Section 9.3 =E2=80=94 GAAP Multicast Group Allocation Ranges<br>
<br>
The IPv4 /10 request is very large and the draft already notes that discuss=
ion with IETF and IANA is needed. Please provide stronger justification for=
 the size, expected utilization, collision probability, and why existing al=
location mechanisms or scoped ranges are insufficient.<br>
<br>
For IPv6, please resolve the dependency on the Dynamic Multicast Group IDs =
registry draft as noted above.<br>
<br>
18. Appendix B =E2=80=94 Change Log<br>
<br>
The change log is useful during draft development but is usually removed be=
fore RFC publication. Please remove it before publication, or add a note to=
 remove it or confirm with the RFC Editor if the WG wants to retain it.<br>
<br>
Best regards,<br>
Gunter Van de Velde<br>
Routing Area Director</blockquote></div></div>

--000000000000ac87f20655c1a6b9--


--===============5799601605528147001==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGltIG1haWxp
bmcgbGlzdCAtLSBwaW1AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byBw
aW0tbGVhdmVAaWV0Zi5vcmcK

--===============5799601605528147001==--