Summary

  • RFC 9083 assigns a top-level RDAP notices array to the service providing the data or to the response as a whole. It is not an attribute of the IP network, ASN or organisation described in the lookup.
  • ARIN’s live notices point to its service terms and inaccuracy-reporting process. They govern use of ARIN’s data and offer a correction channel; they do not state the registered network’s peering, transit, filtering or customer policy.
  • Analysts should preserve notice fingerprints with the query, but route operational claims to routing observations, operator statements and other evidence produced at the layer being asserted.

A label attached to the response

An ARIN RDAP lookup for an IP network can return a compact set of notices above the registration object. In a current response, those notices included “Terms of Service,” “Whois Inaccuracy Reporting” and a copyright notice. The first linked to ARIN’s Whois terms with the relation terms-of-service; the second linked to ARIN’s reporting procedure with the relation inaccuracy-report.

Their placement is not incidental. RFC 9083 defines notices as information about the service providing RDAP information and/or the entire response. It contrasts them with remarks, which describe the object class that contains them. The standard also says the notices array appears only in the topmost object of a response. A parser that copies a top-level notice into a network profile as though it were a network property has changed the subject of the evidence.

This distinction remains true even when a notice’s wording feels operational. The response is about a number resource, and ARIN’s terms permit uses connected with network research and coordination. But the speaker in the notice is ARIN, the service operator. The governed act is querying or reusing registry data. Neither proximity nor vocabulary turns that service condition into a statement made by the registered organisation.

Terms for the reader, not policy for the network

ARIN’s linked Whois Terms of Use form an agreement between ARIN and a user of the service. They address permitted research, operational coordination, reuse restrictions, warranties, liability and dispute handling. Those are consequential conditions for an analyst collecting evidence. They should be recorded with a capture and respected when data is stored, repackaged or shared.

They answer a different question from a network’s operating policy. A resource holder’s peering rules, transit purchases, prefix filters, routing-security practice, customer acceptance criteria and incident procedures are not supplied by ARIN’s service terms. An analyst cannot cite the terms-of-service notice to prove that the holder accepts or rejects a route, carries another network’s traffic, or has agreed to a particular operational duty.

The clean model has three parties: ARIN operates the registry service; the querying user accepts conditions on use; the registration object describes public registry information about a resource and associated entities. Sometimes one organisation may occupy more than one role in a wider transaction, but the RDAP notice does not establish that convergence. Evidence must preserve the role in which each statement was made.

A reporting link is not an adverse finding

The inaccuracy notice creates another tempting shortcut. ARIN places a reporting link in ordinary responses so users have a route for raising suspected errors. ARIN’s first-party guidance separates correction of one’s own record from a report about somebody else’s record. It says staff will review and investigate a third-party report and act on a confirmed inaccuracy.

The generic presence of that link therefore proves neither that a report has been filed nor that the displayed record is wrong. It is a service-wide affordance, comparable to a correction link printed on every page. Treating it as an adverse flag against the queried organisation would invert its function and manufacture a fact that the response never asserted.

If a discrepancy matters, the reproducible approach is to record the exact query and response, identify the field in dispute, preserve the comparison source and file the appropriate report. Any later conclusion should be tied to ARIN’s response to that case or to corrected registry data, not to the existence of the generic notice.

Capture notices as their own evidence layer

A defensible RDAP capture should hash the response and separately fingerprint the ordered notice set: title, description strings, link target, link relation and media type. It should also retain the query URL, retrieval time and the version or effective date visible on each linked policy page. This makes it possible to distinguish a changed registration object from a changed service notice.

That separation prevents false change alerts. A copyright year can advance while the network record stays identical. ARIN can revise service terms without any action by a resource holder. A reporting URL can move while the underlying registered range remains unchanged. Conversely, a network object can change while the notices remain stable. One response contains both layers, but they have different owners and change mechanisms.

The notice fingerprint is useful provenance. It tells a later reviewer which conditions and correction route accompanied the lookup. It is not a shortcut around the underlying evidence. For object claims, cite the object fields and their scope. For service claims, cite the notice and linked ARIN page. For operational claims, leave RDAP and examine the operational layer.

The routing boundary

BGP makes the boundary concrete. RFC 4271 defines a route as destinations paired with path attributes and describes routes being advertised between BGP speakers in UPDATE messages. ARIN’s top-level notices carry none of that state. They do not show an announcement, withdrawal, AS path, selected route, forwarding decision or measured packet path.

An RDAP response can still be an important input to routing research. It can identify the registry context for an address block or ASN and provide public contact and registration data. But a conclusion about live routing requires contemporaneous routing observations, and a conclusion about commercial transit requires contracts or reliable statements from the parties. The notice layer cannot inherit authority from those absent sources.

Sources and authority

The protocol boundary is defined by RFC 9083, section 4.3: https://www.rfc-editor.org/rfc/rfc9083.html#section-4.3 . The current ARIN response examined for this briefing is https://rdap.arin.net/registry/ip/8.8.8.8 . ARIN’s linked service terms are at https://www.arin.net/resources/registry/whois/tou/ , and its correction procedure is at https://www.arin.net/resources/registry/whois/inaccuracy_reporting/ . The routing-layer comparison is RFC 4271, section 3.1: https://www.rfc-editor.org/rfc/rfc4271.html#section-3.1 .

ARIN’s response and pages are primary evidence for its service and process. RFC 9083 defines the scope and shape of RDAP notices. RFC 4271 defines the routing information that BGP actually exchanges. None of these sources should be made to speak for a different layer.