GOpenCNR registry data policy

What this policy decides

What the GOpenCNR registry publishes and through which interfaces, what it withholds, what anyone who takes the data in bulk may do with it, and how withheld data is disclosed. It applies to every object in the registry: holders, pools, allocations, ASNs, routes, the audiences GOpenCNR uses, endpoints, nodes and services.

Gelhaus Solutions is the controller for all registry data, and every request about it comes to us. What we process about you beyond the registry is in the privacy notice.

What is public, and why

A registry exists so that others can rely on it. These parts of it are public:

• The holder's handle. A person's name appears only if that person chooses to show it. A verified organisation appears with what the organisation verification terms publish.
• For each allocation: the prefix, its size, the pool it came from, when it was allocated and until when it is reconfirmed, its status (allocated, suspended or quarantined), whether it is announced, and whether it is open or closed.
• For each route: the prefix, its origin ASN and the result of route origin validation.
• For each ASN: its holder, when it was issued, the providers it names for ASPA, and how many open and closed routes it originates.
• The abuse relay address of every holder, abuse+<handle>@relay.csr.gplatform.org.
• For each pool: its prefix, its purpose, its sizes and the GOpenCNR Community Council motion that created it.
• For each closed prefix, the same as for any other: the prefix, the holder's handle, its origin ASN and its ROA. Only its reachability is closed.
• The RPKI repository: a ROA for each route, with the exact prefix and its origin ASN, and the ASPA objects.

Each of these is public for a reason:

• Uniqueness is the registry's purpose, and it can be checked only if everyone can see who holds what.
• Routing depends on it: other networks' filters, route origin validation and IRR tools need prefixes and their origins.
• Saying that a prefix is closed tells everyone outside its audience not to expect to reach it, without saying who may: the audience's members and the routes to the prefix stay private.
• Reaching a holder about abuse must be possible for anyone affected, and the relay makes it possible without disclosing the holder's address.

We rely on Art. 6(1)(f) GDPR for this, the legitimate interest being a registry that anyone can route by and check.

What is redacted

• Admin and tech contacts are kept for every holder and are visible to Tier 0 only. RDAP answers carry them as redacted, following RFC 9537, so that an answer shows that they exist and were withheld on purpose.
• A person's name, unless that person chooses to show it. The handle stands in for it everywhere.
• The holder's own address for abuse reports. Only the relay address is published.

What never leaves

None of the following is in any public interface, export, copy or history:

• Endpoints, the public IP addresses at which members' routers and devices are reached. They are stored encrypted and shown only to Tier 0 and to peers the member accepted. The transparency log keeps only a salted hash (see "History").
• Who is in an audience. The audience's holder and Tier 0 see its members; every other member sees only its own inclusion; the transparency log keeps each change only as salted hashes.
• Admin and tech contacts, except to Tier 0.
• A person's legal name and country, given for sanctions screening, which only Tier 0 sees, and whether a sanctions review exists, which only the holder and Tier 0 know. No screening outcome is written to the transparency log.
• Closed routes, as the hubs carry them, except towards their audience. The looking glass shows a closed route only to signed-in members of its audience; it never appears in the collector's published dumps and never crosses an interconnect.

The only other way any of this leaves is a disclosure the law requires, as set out under "Disclosing redacted data" below.

RDAP

RDAP answers for the IP networks and autonomous system numbers in GOpenCNR, served from cnr.gplatform.org, with queries as RFC 9082 defines them and responses as RFC 9083 defines them. Redacted fields are marked as RFC 9537 sets out.

GOpenCNR's space is private address space, so IANA's RDAP bootstrap registries do not list it. We publish our own bootstrap file, covering GOpenCDR's names and GOpenCNR's numbers together, so that an RDAP client configured with it finds the right server for both.

Whois on port 43

A whois service on port 43 answers for the same objects with the same public data, in plain text, for tools that do not speak RDAP.

RPSL, the IRR and NRTMv4

The registry is exported in RPSL and served by an IRR server in mirror mode, so that bgpq4 and other IRR tools can build filters from it. The IRR server is fed only from the registry and is never written to directly: a change goes into the registry, signed by its holder, or nowhere. RPSL objects carry the same public data, and no contact other than the abuse relay address.

The registry is also an NRTMv4 source, so that IRR mirrors can follow its changes as they happen.

dn42-format exports

For tools built for dn42, we publish registry objects and ROA files in the formats dn42's tooling reads, a dn42-style JSON file of ROAs, RFC 8416 SLURM files for members who also validate the public RPKI, and BIRD ROA tables. They are generated from the same data as everything else, and carry nothing that is not public above.

The signed export and its git copy

The registry publishes a signed export: snapshots, a journal of every change, and incremental reads of what changed since a given point. Anyone can mirror it and check it against the transparency log. The same export is published as a read-only git repository that anyone can clone and diff.

Git is never where the registry is kept. The registry is the truth, and the git copy follows it. A holder who manages its objects from its own git repository sends its signed commits through the API, where they become ordinary changes.

The export and its git copy hold the public data described above, and nothing else.

Taking the data in bulk

Anyone may download, mirror and process the exports and query the interfaces in bulk, without asking us first, for:

• routing: building filters, validating route origins, running IRR mirrors and route servers;
• research into routing, addressing and the registry itself;
• mirroring: keeping copies that others can check against the transparency log.

They may not be used:

• for marketing, or to contact holders about anything other than the matter the data is published for;
• for spam, including through the abuse relay addresses;
• to re-identify people: to link handles, space or relay addresses with other data in order to find out who a person is, where they are, or anything else they chose not to publish.

Attribution is not required, unless a file says that data in it comes from a source that requires it.

Choosing to show your name

A person who holds space appears under a handle. You may choose to show your name with it, and withdraw that choice at any time. A withdrawn name leaves the registry from that moment on: it disappears from the current pages, from every interface and from every later state of the export.

Earlier states keep it, because the registry's history shows what was public and when, and copies others have taken of the export are beyond our reach. Decide with that in mind. If you need your name removed from the history we publish as well, write to contact@gplatform.org, and we weigh the request case by case under Art. 17 and 21 GDPR.

Reaching a holder

Most people who ask who is behind a prefix want to reach whoever runs it. The abuse relay address does that: a message to abuse+<handle>@relay.csr.gplatform.org is forwarded to the holder without disclosing the holder's address. Each sender may send 20 messages an hour through it, with evidence of up to 20 MB, and is contacted back through the relay only after agreeing to that. The relay keeps a log of senders' addresses and outcomes for 12 months.

Abuse may also be reported to abuse@gplatform.org; the abuse and sanctions policy sets out how a report is handled.

Disclosing redacted data

Authorities receive redacted data, and endpoints, only under the authority request policy. Orders of German courts and authorities, and European Production and Preservation Orders under Regulation (EU) 2023/1543, are answered directly after they are checked. Other foreign requests are answered only through German mutual legal assistance. We disclose voluntarily only to prevent an imminent danger to life or limb, and never telecommunications traffic data: that is passed on only under a law that expressly refers to telecommunications (Section 3(3) TDDDG). Records of requests from authorities are kept for 5 years after the request is closed.

Everyone else receives redacted data only with the holder's consent, or where a law obliges us to disclose it. A legitimate interest alone is not enough. This is narrower than GOpenCDR's registration data disclosure policy, which governs names and which this policy does not change.

How to ask. Write to contact@gplatform.org with "Registry data" in the subject line. Say who you are, which prefix, ASN or holder the request concerns, what you need, why, and on what legal ground, and attach the legal process or the holder's consent. Where neither is attached and no law obliges us, we ask the holder whether they consent, and disclose only what they agree to.

What is disclosed. The least that serves the purpose, to the requester alone, in text form, with a note that it may be used only for the purpose stated and must be deleted when that purpose is met.

Telling the holder. The holder is told who asked, why and what was disclosed, unless the law forbids it, and as soon as it no longer forbids it.

Counting. Every request and its outcome is counted in the joint transparency report published every six months.

Corrections

You correct your own objects through the portal, the command-line tools or the API, as changes you sign. If data about you is wrong and you cannot change it yourself, or an object names you or your resources wrongly, write to contact@gplatform.org. Tier 0 corrects it with a change of its own, which you are told about and which the transparency log records.

A correction is a new state. The history keeps the old one.

History

Every object has a public timeline: each change with its diff and the signature it carried, drawn from the transparency log. The whole registry, or any object in it, can be read as it stood at any past moment. History covers the public data only. Endpoints and audience members appear in the log only as salted hashes: each gets a random 32-byte salt, kept encrypted beside the record and given to the holder, and for an endpoint to the peers the holder accepted, with the receipt, so that they can verify the entry. Nobody can guess the input back from the log.

Public history is kept for good: the past states, the change journal and the git copy. A registry whose past can change cannot settle a dispute. What is not public about a resource is deleted 12 months after the resource ends.

Changes to this policy

A material change is announced to holders at least six weeks before it takes effect, as the general terms of service set out. Every version is kept in the document archive.