Summary

  • ARIN’s current comments for Draft Policy ARIN-2026-1 say it is being proposed jointly with the IETF TIPTOP working group, while ARIN’s index still records the policy as under discussion.
  • The cited draft-li-tiptop-address-space is an individual Internet-Draft without IETF endorsement or formal standing; on 10 June 2026, the TIPTOP chairs reported support for work on the problem but no clear consensus to adopt that draft as-is.
  • A versioned cross-institutional status receipt should name the exact artifact, actor, procedural state and next authorising event instead of asking one word—joint—to represent every layer.

One sentence on ARIN’s policy page crosses an institutional boundary that the page it links to keeps open. The current comments for ARIN-2026-1 say: “This is being proposed jointly with the IETF TIPTOP working group.” The linked IETF Datatracker record identifies the address-space document as an active candidate, records that a working-group adoption call was issued, and carries the standard warning that an Internet-Draft is not endorsed by the IETF and has no formal standing.

The difference is not a semantic curiosity. Joint can describe contact among authors, shared interest in a problem, coordinated presentations, parallel work, an adopted work item, consensus on a particular model or an institutional commitment to act. Those states are not interchangeable. A reader who sees only the ARIN sentence cannot tell which one is meant.

There is no evidence here of deception or improper coordination. Authors and participants may have worked closely across both communities. TIPTOP plainly has an interest in networking beyond Earth. The narrower problem is evidentiary: public attribution should not compress several independent decision systems into one adjective.

One problem, eight different states

The problem can be shared before the solution is shared. That is normal standards work. A working group can agree that an addressing question deserves attention while disagreeing about the allocation model. A registry community can discuss a policy while the IETF develops protocol architecture. IANA can later perform an allocation only after the relevant technical and institutional decisions exist.

State What the public record would have to show
Interest Participants or a charter identify the problem as worth studying
Authorship Named individuals submit a particular text
Presentation A draft appears on a meeting agenda
WG adoption Chairs determine that the group will develop that draft as a working-group document
Consensus The working group supports a defined technical result
Institutional determination IETF, IANA, the RIRs or an RIR board takes its own required action
Implementation The policy and operational dependencies are satisfied
Activation A registry entry, delegated block and effective process actually exist

The TIPTOP charter proves that there is an active technical venue with approved work. It does not by itself adopt an address-allocation model. The distinction becomes visible in the IETF 126 agenda: adopted use-case and architecture work appears under WG Document Presentations, while draft-li and a competing proposal appear separately under Address Space Discussions.

That agenda is a compact institutional map. It says that architecture work has entered the group’s document stream and that the allocation question remains a discussion between models. A presentation may influence a decision. It is not the decision.

What ARIN-2026-1 actually establishes

ARIN’s draft-policy index lists ARIN-2026-1 as a Draft Policy under discussion, with a current version dated 27 May 2026. It does not list it as adopted or implemented. The policy page proposes a dedicated IPv6 block for networks operating beyond geostationary Earth orbit and says the block should not be constrained by terrestrial geography.

The page also states its dependencies with unusual clarity. Its problem statement says implementation depends on an IETF and IANA determination that a distinct block is appropriate, concurrence by the RIRs, and an ARIN Board determination that serving such networks is within ARIN’s mission. Those are separate institutional acts. The draft itself cannot substitute for any of them.

The embedded ARIN staff and legal review dated 1 April is equally important. It says the proposal was not implementable as written and identifies four prerequisite conditions. The later text may evolve as the discussion continues, but the public state remains a proposal. Calling it joint does not make it executable.

This is not a verdict on whether networks beyond Earth should receive ordinary globally routable addresses, a special block or something else. It is not a technical comparison of delay-tolerant architectures. The evidence question precedes those debates: what exactly has each institution agreed to do?

What the IETF adoption outcome establishes

The strongest evidence is the 10 June 2026 message from the TIPTOP chairs. It does not reject the problem. The chairs report support for working on the address-space question. But they also say they do not see clear working-group consensus at that time to adopt draft-li-tiptop-address-space as-is.

That second clause matters because the call was about a specific artifact. Interest in the subject did not settle the registry model. The chairs pointed to a different approach in draft-kumari-tiptop-address-space and called for a design team and clearer comparison.

Both address-space texts are individual Internet-Drafts. Both therefore carry the same basic warning: anyone may submit one, and publication does not mean IETF endorsement. Their models are materially different. The Li draft describes a dedicated space registry architecture; the Kumari draft has IANA reserve IPv6 space and delegate it through the existing RIR structure. A generic statement that a policy is joint with TIPTOP does not tell the reader which model the group has selected, because the checked record shows that it had not selected draft-li as-is.

The adoption outcome is also bounded in time. It does not prove permanent rejection. A design team could reconcile the drafts, produce a third model, or lead to later consensus. Nor does it show that the IETF opposes ARIN-2026-1. It proves one narrower fact: on 10 June, problem interest existed without clear consensus to adopt the cited model as a working-group document in its then-current form.

Architecture is not allocation

The adopted TIPTOP IP architecture draft helps expose another easy compression. It is a working-group document. It cites draft-li as work in progress. It also says that the architecture memo itself makes no request to IANA.

So even a document that has crossed the working-group adoption threshold does not automatically create an address allocation. Architecture, allocation policy, registry delegation and operational activation remain different objects. An adopted architecture can define requirements while leaving the allocation mechanism open.

The frozen IANA IPv6 Global Unicast Address Space registry, last updated 10 October 2025, contains no dedicated outer-space allocation in the checked snapshot. That absence is not a prediction. It does not prevent a future allocation. It simply prevents a proposal or architecture document from being narrated as an already-existing registry state.

The sequence matters because each step has a different accountable actor. The IETF can standardise technical behaviour. IANA can maintain and execute parameter assignments under an authorised process. RIR communities can consider regional policy. RIR boards can decide questions assigned to corporate mission and risk. None gains the power to speak conclusively for the others merely by linking their documents.

A receipt for cross-institutional claims

The smallest repair is not to ban the word joint. It is to attach a receipt whenever the word attributes work to another institution. The receipt should be versioned because both documents and procedural states change.

Receipt field Minimum answer
Claimant Who publishes the attribution
Referenced object Exact document name, version, hash and stable URL
Attributed actor Authors, participants, chairs, working group, IETF, IANA, RIRs or board
Relationship Consultation, co-authorship, presentation, adoption, consensus, approval or implementation
Authorising event Mail, minutes, adoption result, ballot, resolution or registry action
Effective interval When the claim became true and whether it still is
Competing objects Alternative drafts or models still under consideration
Dependencies Decisions required before implementation or activation
Correction lineage Supersession, withdrawal, revision and public correction

For ARIN-2026-1, such a record could say that named participants coordinated on the problem, that ARIN’s proposal was under discussion, that draft-li-02 was the cited candidate, that an adoption call had been issued, and that the chairs later found no clear consensus to adopt it as-is. If a subsequent design-team text becomes a TIPTOP working-group document, the record can add that event without rewriting the earlier state.

The actor field is crucial. IETF participants, TIPTOP authors, TIPTOP chairs, TIPTOP working group and the IETF are different scopes. The first two may collaborate without an institutional decision. Chairs can report a consensus outcome but do not manufacture consensus. A working-group document has a stronger procedural status than an individual draft, while IETF consensus and publication as an RFC require further steps.

The relationship field is equally important. Consulted with is weaker than co-authored; presented to is weaker than adopted by; adopted for work is not the same as approved as the final model; and all of them are weaker than an operational allocation. Precise verbs do not obstruct collaboration. They preserve its actual stage.

What this record does not prove

The checked sources do not prove bad faith by ARIN, the proposal’s authors or TIPTOP participants. They do not prove that no private coordination occurred. They do not establish a legal conclusion about ARIN’s mission, address ownership or jurisdiction. They do not tell us which technical model is best.

They also do not prove that draft-li will never be adopted. The 10 June result was an invitation to do more comparative work, not a constitutional prohibition. Later evidence must be allowed to change the status.

What the record does prove is sufficient and narrower. ARIN-2026-1 was under discussion. Its comments used a joint attribution. The linked address-space draft had not become a TIPTOP working-group document as-is. The chairs recorded support for the problem but no clear adoption consensus. A competing model remained in view. The architecture document and the allocation proposal had different statuses. No dedicated IANA allocation appeared in the frozen registry snapshot.

Those facts do not cancel cooperation. They show why cooperation needs a ledger.

Sources