Summary

  • Adding an org: reference requires approval for the object being changed and separate authorisation from a maintainer named in the referenced object's mnt-ref: attributes.
  • The successful update proves that the database accepted that reference through its configured authorisation path. It does not prove corporate ownership, membership, contractual control, current network operation or BGP responsibility.

Two locks on one reference

One short database edit can involve two different authorities. A maintainer must first be able to update the object that will carry the org: attribute. The organisation object being referenced must then permit that reference through a maintainer named in mnt-ref:. RIPE's current documentation says the second check is additional to the first. If no suitable mnt-ref: authorisation is available, the software does not fall back to mnt-by:; the update fails.

This design answers a precise accountability question: was the cross-object reference added through the authorisation path that the referenced object exposes? It prevents any maintainer who can edit one object from freely attaching an existing organisation object to it.

The distinction between mnt-by: and mnt-ref: matters. mnt-by: protects creation, deletion or modification of the object in which it appears. For an organisation object, mnt-ref: names the maintainers whose credentials may approve the creation of references to that object elsewhere. A party can therefore be authorised to change a resource object without being authorised to associate that resource object with a particular organisation.

What the accepted link establishes

After both checks pass, the public record supports a narrow statement: at the observed time, the RIPE Database contained an org: reference that had satisfied the configured update authorisations. Analysts should preserve the referencing object, the organisation identifier, the relevant maintainer identifiers, the database source, the retrieval time and—when available—the update history.

That is stronger than treating the link as unauthenticated free text. It is still weaker than many conclusions readers may attach to an organisation name. The database transaction does not publish the private evidence, agreement or organisational decision that motivated the reference. Nor does it encode a universal legal meaning for every link.

RIPE's data-modelling guidance describes organisation objects as a way to centre related human and Internet resources around an organisational identity. It also recognises that complex organisations may use additional organisation objects for different parts of their structure. The model is deliberately useful for grouping and management; that utility does not make each reference a corporate registry filing or an operational topology measurement.

Reference is not responsibility

RIPE Database Working Group material identifies the attribution risk directly: an inappropriate reference can create the impression that an unrelated party is responsible for an object. mnt-ref: reduces that risk by requiring authorisation from the referenced side. It cannot, by itself, settle every question about the relationship.

Corporate ownership needs current company filings or official disclosures. Group membership may require organisational records or governing agreements. Contractual responsibility needs the relevant contract or an authoritative statement. Network operation needs current evidence about the team, systems and credentials involved. BGP origin, transit and reachability require separately timed routing and measurement evidence.

Those questions can produce the same answer as the org: reference, but they do so through different evidence. The safe conclusion preserves both the value and the limit of the database control: the reference was authorised for inclusion; the broader relationship remains a claim to verify.

Sources