Summary
- James Kennedy proposed requiring the existing
org:reference on RIPE Database inetnum records when an LIR assigns or sub-allocates PA space to another organisation. - The proposal would make downstream users easier to identify. LIRs would have to maintain the extra records, and the reference would matter only if it names the organisation actually using the block.
Analysis
The record pointed to an intermediary. The network operator still could not tell who was using the IPv4 block or whether the failed connection affected a critical service. That was James Kennedy’s example at RIPE 93, where he asked the Address Policy Working Group to discuss a new requirement for downstream users of Provider Aggregatable (PA) space.
RIPE’s current IPv4 policy lets an LIR sub-allocate space to multiple downstream network operators. It keeps the LIR contractually responsible for compliant use and says allocations and assignments must be registered in the RIPE Database. The policy sets the registration duty; the Database’s object rules determine what each record identifies.
That distinction sits inside two RIPE documents. RIPE-767, the Database Requirements Task Force report, recommends that resource holders have discretion over ordinary PA assignment records. It separately strongly recommends documenting an IPv4 sub-allocation or assignment when the resource goes to another entity, and recommends Assisted Registry Checks to verify published data. RIPE-826, the current policy, still requires registration of all assignments and allocations.
The org: attribute already exists. In the RIPE Database’s inetnum template it is conditional, with software business rules requiring it in specified cases, including objects maintained jointly with RIPE NCC. Kennedy wants the attribute required for the narrower case where an LIR’s PA block serves another organisation. He proposed no new field, new contact system or change to an LIR’s own infrastructure records.
The microphone queue exposed the price of that extra line. Gert Döring said his LIR would need engineering work to generate more organisation records, with little benefit where its customer data was already accurate. Peter Hessler raised a different weakness: duplicate or fictitious organisation records could satisfy a field requirement and still point responders nowhere useful. Kennedy accepted that both costs and benefits belonged in the proposal.
The decision turns on the record’s job. If org: identifies the downstream operator, a responder can reach the people who can act. If it repeats the LIR or points to an unverified shell entry, the database gains another row and the operator gains no answer. Kennedy said his draft was unpublished when he spoke. The current public documents give no count of PA records missing a downstream organisation reference; that number would show whether LIRs face a narrow fix or a system-wide workload.
Sources
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance





