Summary

  • RFC 8602, co-authored by Jari Arkko and Ted Hardie, updates the TRIP registry rules so IANA no longer collects postal addresses for TRIP Attributes and ITAD Number registrations, and it says that previously collected postal addresses were removed. The RFC identifies no use for those addresses and names a privacy benefit from omission.
  • That is a field-level rule, not a claim that every old copy disappeared or that a registry entry proves a route, a peer, a deployment or a successful call. A useful registry keeps the minimum information its documented operation needs, with a clear reason for every field that remains.

The field survived its reason

Registries acquire a particular kind of institutional gravity. A field is added because an early form had room for it, because a neighbouring process used it, or because a historical template was copied forward. Years later, the field can look inevitable merely because it is familiar. Operators and requesters continue supplying it; reviewers assume it must be relevant; mirrors and exports keep carrying it. The record's age starts to impersonate a purpose.

RFC 8602 is a compact corrective to that tendency. It updates the IANA registry rules for Telephony Routing over IP, or TRIP, by ending the requirement to include postal-address information in contact data for TRIP Attributes and TRIP IP Telephony Administrative Domain, or ITAD, registrations. The document also says that IANA removed postal addresses previously collected in those registries. Its stated reason is unusually direct: no use for the addresses was identified, and omitting them provides a privacy benefit.

The significance is not that every registry should become sparse by instinct. A request record still needs the identifiers, policy, reference and other evidence that let a steward process an assignment and let readers understand it. The significance is that the burden of proof runs in the right direction. A field remains because a defined registry action needs it. It does not remain simply because the first version of a form asked for it.

That reversal matters more than it first appears. A public contact field can create correction work, inaccurate historical residue, exposure through export and a false inference that the registrant can be reached or authorised at the displayed location. Yet a field that is truly necessary can be equally important: a missing reference or an ambiguous identifier can make a record impossible to interpret. The discipline is not “collect less” as a slogan. It is “collect what the operation can explain.”

What RFC 8602 actually changes

The scope has to remain narrow. The RFC does not replace TRIP. It does not revise how a location server forms a route, chooses a peer, advertises reachability or accepts a signalling exchange. It updates two IANA registration-rule surfaces originally associated with RFC 3219: the TRIP Attributes registry and the ITAD Number registry.

RFC 3219 describes TRIP as a policy-driven, inter-administrative-domain protocol for advertising the reachability of telephony destinations and attributes of routes between location servers. Its protocol terms concern route information, peers, domains and messages. A registry field about a contact address is a different kind of object: it is an instruction about what the IANA process collects while recording a specified assignment.

Those two layers can be related without becoming interchangeable. A registry may identify an ITAD number and its governing documentation; it does not report that a particular location server is currently reachable. An RFC can say that a postal address is no longer needed for registration; it does not reach into a vendor archive, an old exported spreadsheet, a private customer file or an unrelated database. Nor does the absence of a postal address make a route valid, a peer trusted or a call complete.

The IANA protocol-registry index now points to RFC 3219 and RFC 8602 for the TRIP ITAD Number registry and lists its First Come First Served policy. That is useful public provenance. It tells a reader which rules define the registry and what assignment procedure is named there. It is not a deployment census, a privacy audit of every copy, or an authority grant to anyone who sees the number.

A registry is a coordination surface, not a biography

The mistake on one side is to treat a registry as a disposable form. The mistake on the other is to treat it as a biography of each registrant. Neither makes the shared namespace more reliable.

RFC 8126 gives the first boundary. When a specification creates or changes a registry, it should state the registry's name, its policy, the required information and the format of its entries clearly enough for IANA to perform the requested action. Technical explanation belongs where the protocol defines it; the IANA Considerations section is a concise instruction surface for the registry operation.

That instruction surface supports a practical field test. For each candidate field, an editor or steward should be able to answer: what decision does this datum support; who needs it; where is it exposed; how is it corrected; when is it removed; and what breaks if it is absent? If the answer is an inherited habit rather than an operation, the field deserves review. If the answer is a specific assignment, review or appeal function, the field deserves a precise schema and a correction path.

This is a minimum-initial-specification problem in the sense developed by Heng Lu. The common registry layer should impose the minimum stable information needed for coordination. It should not absorb local or historical detail merely because the common layer can store it. Local systems may need a fuller contact file, a contract, a customer record or a private incident contact. Those systems also carry their own authority, retention rule and access control. Putting their contents into a public protocol registry does not make them more authoritative; it only changes their exposure.

Removal is a receipt, not a magic eraser

The phrase “previously collected postal addresses were removed” has a real but bounded meaning. It records an action concerning the named IANA registry. It is more than an aspiration, and less than a universal deletion certificate.

An honest removal receipt identifies the affected registry, field, rule version, action date, record population or scope if known, and the public representation whose values changed. It also distinguishes retained assignment identifiers from the removed field. That allows a future reader to see what the registry is claiming without inventing a claim about every historical cache, archived copy, subscriber export, search index or private system.

The difference is protective for both privacy and operations. Overclaiming can create a false sense that an individual has no remaining exposure anywhere. Under-documenting can leave reviewers unable to tell whether a field was removed by policy, omitted accidentally, or merely hidden from one rendering. A small, specific receipt gives the public record an auditable boundary.

The same approach applies before collection. A form can record the purpose for a requested field, the rule authorising it, its expected visibility, the correction route and the condition for review. It need not publish personal data to prove that the form has a purpose. A field inventory can be public while sensitive values remain in the system that legitimately needs them, if any.

Credit a documented contribution without inventing control

The RFC Editor lists Jari Arkko and Ted Hardie as RFC 8602's authors. Arkko's IETF Datatracker profile records a public professional biography, RFC work and IETF roles. Those sources make the attribution traceable and provide appropriate context for a person-centred article.

They do not make Arkko the owner of TRIP, the IANA registry operator, or the decision-maker for a present network. RFC 8602 is an IETF standards record. IANA maintains the named registry under the documented policy. A registrant, operator or data controller still has to establish its own current procedures and evidence. The useful conclusion is institutional rather than heroic: a carefully bounded standards update can remove a needless requirement without pretending that publication itself controls all copies or all deployments.

Evidence limits

The cited materials do not identify every postal address once held by the registries, every historical replica, or the retention practice of systems outside the named IANA surface. They do not show whether TRIP is presently deployed by any named operator, whether a specific ITAD is active, or whether a route and telephony service are functioning. They do not demonstrate a general privacy rule for every IANA registry.

The proposed field-purpose receipt is an operational inference from the documents' boundaries. It is not a claim that RFC 8602 mandates one global schema, proves universal compliance or resolves all data-governance questions. Its value is smaller and more durable: it makes every continued public field answerable to the work it is meant to do.

Sources