Summary

  • Revision 25 of the PIM working group's GAAP Internet-Draft explicitly says GAAP is a protocol, not a Python library or API. Its pseudo-Python calls illustrate one integration choice; an implementation may expose another interface or none, provided it follows the on-wire Claim protocol. Revision 24 already labelled the example illustrative and non-normative.
  • The revision also says a Claim has four wire fields, not a longer list implied by explanatory subsections, and expands the warning about unauthenticated ChaCha20. Neither passage proves a changed packet format, a new security ban, an actual attack or a deployment.

The decision facing a software team is not whether to call a function gaap.allocate(). It is whether independently built participants exchange and interpret the same Claim. The distinction matters because GAAP is designed to help allocate multicast group addresses without a single assigning server. A code snippet is easy to copy; a packet contract is what remote peers can actually observe. In the 25 September revision of draft-ietf-pim-gaap, section 5 now carries the heading “Illustrative GAAP API” and states the distinction directly: GAAP is a protocol, not a library or a Python API. The pseudo-Python is explanatory rather than a condition for conformance.

That clarification is narrower than the tempting headline “Python API dropped.” The preceding revision already called the API illustrative and non-normative. Version 25 does not revoke a formerly mandatory language binding. It removes room for a different misunderstanding: that the document standardizes a particular library boundary, or that every application must expose the same calls. It explicitly permits any interface, including no programming interface at all, if the implementation follows the Claim protocol on the wire. One system might integrate through a daemon, another through embedded software.

Those are examples of possible local architecture, not implementation evidence for GAAP.

Section 4 makes a parallel distinction within the Claim description. The draft identifies four fields in the record: an IPv4 multicast group address, an IPv6 multicast group address, a timestamp and a group name. Subsequent text explains how fields are used, compared and parsed. Version 25 says those explanatory passages are not additional fields. An engineer comparing revisions should therefore not infer a fifth field, altered packet order or a format migration from this editorial reorganization. The wire boundary is being made more legible; no observed interoperability result follows from that alone.

The security edit supplies a second test of what a label can obscure. Revision 24 already required integrity when ChaCha20 is used and said the cipher without a message authentication code must not be used alone. Revision 25 adds the reason: a stream cipher without authenticated integrity is malleable. An on-path adversary could flip ciphertext bits so that a recipient decrypts a different group address, timestamp or name without detection. The draft argues that a false expectation of protection may be worse than openly using the base unencrypted mode.

This is an explanation of a design hazard, not a newly discovered GAAP exploit and not proof anyone has deployed that configuration.

The two clarifications form one governance boundary. Shared rules should say what remote peers must be able to rely on: the Claim exchange, its four actual fields and the integrity property if encryption is chosen. They need not dictate the internal interface through which an application asks for an address. Equally, leaving application choices local does not let an “encrypted” badge stand in for integrity. A test that merely finds a Python method with the right name, or sees ciphertext on a link, would miss the substance of the specification. This is an editorial interpretation of the draft, not a conformance programme announced by the IETF.

The Datatracker identifies revision 25 as a PIM working-group Internet-Draft in IESG Evaluation, with AD Followup and a proposed Experimental status. It is not an RFC. A previous BTW report on GAAP-23 examined fixed address ranges and what happens to same-name claims after partitions reconnect. Those questions remain background here; revision 25's news is the sharper boundary between wire rules, local APIs and the evidence required for integrity. It does not settle the prior convergence issue.

Sources