Summary

  • RIPE-738 says twice what an LIR must be able to show “in case of an audit”, but it contains no general reference to RIPE-694, the document that sets out audit types, scope, time frames, outcomes and appeal.
  • RIPE NCC Registration Services says the missing link does not prevent IPv6 audits. It is considering a clarifying proposal, not announcing a policy change; a versioned policy-to-procedure crosswalk would make the existing mandate easier to inspect.

Policy is often read at the moment it becomes inconvenient. A network planner opens the IPv6 allocation document to check whether a large End Site assignment can be justified. A database operator looks for the statistics behind an AGGREGATED-BY-LIR object. Both eventually meet the same phrase: “in case of an audit”. Neither is shown where the audit comes from or what happens next.

That is the documentary seam RIPE NCC Registration Services placed before the Address Policy Working Group on 2 July 2026. Marco Schmidt wrote that reviews and audit activity had exposed parts of the IPv6 policy’s post-provisioning lifecycle that could be clearer and more consistent. The word “audit” appears, he observed, but the policy has no general reference to the audit procedure, unlike the IPv4 policy.

The limiting sentence matters more than the criticism: Schmidt explicitly said the reference is not required for the RIPE NCC to audit IPv6 resources. The issue is visibility of an existing mandate, not whether a mandate exists.

Two duties, no onward route

The frozen RIPE-738 text contains the phrase “In case of an audit” exactly twice. Section 5.4.2 requires an LIR to present documentation justifying an assignment larger than a /48 to one End Site. Section 5.5 requires statistics for assignments recorded as AGGREGATED-BY-LIR so the RIR can calculate and verify the HD-ratio.

Those are concrete evidence obligations. Yet RIPE-738 does not name or link RIPE-694, RIPE NCC Audit Activity. A reader following only the IPv6 policy can see two possible demands without seeing the larger control path: assisted, selected and reported audits; the relationship between the initiating issue and the audit’s scope; the timetable set for providing material; possible recommendations, correction or contractual consequences; confidentiality; and the route to conflict arbitration.

The contrast with IPv4 is unusually clean. RIPE-826 contains a dedicated section 8.0, “LIR Audit”. It says the community asked the RIPE NCC to audit LIR operations for consistent and fair policy implementation, then points to the audit document. That short join does not create the authority. It lets a reader traverse it.

RIPE-863 completes another part of the picture. It separates due diligence before registration from controls after resources have been registered, and says post-registration accuracy is maintained in part through audits. Read together, RIPE-738, RIPE-694 and RIPE-863 form a lifecycle. Read separately, the IPv6 policy exposes only two evidence moments.

Old wording is the second seam

Registration Services also identified the policy’s “good faith”, renewal and non-renewal passage. Schmidt said its intent remains valid, but that its compliance and non-compliance language has been unchanged since 2002 and can be difficult for readers without the historical context.

That is not an announcement that the passage is defective, unlawful or about to be replaced. The 2 July message asked the working group whether a proposal should be developed. The frozen current-proposals page does not list this idea as a numbered proposal. There is no draft text to evaluate, no impact analysis and no adopted change.

The distinction protects the policy process. A staff observation can identify an operational seam; the community still decides whether and how the policy text should move. Reporting the observation as a completed reform would erase the very governance boundary the discussion is meant to clarify.

Publish the join as a maintained object

A hyperlink would be useful, but a link alone can age badly. The stronger control is a small, versioned audit-authority crosswalk maintained alongside the policy. For each audit-relevant IPv6 clause, it could state:

  • the policy clause and version;
  • the evidence category the clause permits or requires;
  • the governing audit and due-diligence procedure versions;
  • the public audit type and trigger class;
  • the rule for limiting or extending scope;
  • the clock, possible outcome classes and correction path;
  • the appeal route; and
  • a last-reviewed date.

No member, prefix, ticket, suspicion or confidential document belongs in that table. It would map normative text to procedure, not publish case files.

A second, aggregate receipt could show how the framework operates without exposing holders: counts of assisted, selected and reported audits opened and closed; bounded duration bands; broad evidence categories; outcomes such as data corrected, recommendation issued, no further action or escalation; and appeals opened or concluded. These are editorial recommendations, not a RIPE NCC commitment.

Evidence boundary

The sources establish a pre-proposal staff request for feedback, two audit references in RIPE-738, the absence of a general procedural link there, the dedicated IPv4 audit section, and the separate RIPE-694/RIPE-863 lifecycle. They do not establish an unauthorised audit, a live audit case, member confusion or harm, a policy violation, a submitted proposal or any agreed amendment.

Sources