Summary

  • RFC 9083 defines an IP-network name as an identifier assigned to the registration by the registration holder.
  • LACNIC’s current record keeps that label separate from address bounds, handle, classification, parentage, status, contacts and events; routing claims need other evidence.

A label that resembles the range

LACNIC’s live RDAP response covers 200.0.0.0 through 200.0.7.255. Its name is 200.0.0.0 - 200.0.7.255. That string looks authoritative because it repeats the range, but repetition does not change the field’s role.

The response already has startAddress and endAddress for the numerical boundaries. It has handle for the registry identifier, type for LACNIC’s classification, parentHandle for registration hierarchy, status for registry state, and embedded entities for registrant or contact roles. The name sits among these fields; it does not absorb their meaning.

RFC 9083 section 5.4 describes the field narrowly: it is an identifier assigned to the network registration by the registration holder. The standard does not say that it is a verified corporate name, a title deed, a universal key shared by every registry, or a statement about routing.

That distinction matters in joins. A system that treats name as an organization identity can merge unrelated records when holders reuse generic labels, ranges, abbreviations or internal conventions. A system that treats it as an operator identity can attach incidents, traffic or policy responsibility to the wrong party. The safer model keeps the label with its registry, object class, handle, address bounds, endpoint and capture time.

The field is still useful. It can help a reader recognize a record, detect a label change and compare the holder’s naming practice across snapshots. It is evidence about the registration. It is not a shortcut around corporate records, contracts, validated contact data, RPKI, route-origin observations or topology measurements.

Sources