Summary

  • The proposal submitted on 22 September 2014 would have required every AFRINIC Resource Member to register and document each own-network or customer IPv4 assignment of /29 or larger no later than seven business days after assignment.
  • The proposed record was meant to support contactability, operational and security response, proof of utilisation and the assessment of further IPv4 requests. It also contained specific residential and confidentiality accommodations.
  • Its central error was to move from an evidentiary rule to punitive language: unregistered records were called “invalid”, and staff were said to be able to use “any process”, after “approbation by the community”, to “reclaim” resources.
  • AFRINIC is a private technical bookkeeper and coordinator. A missing or late WHOIS row can justify an evidence request, notice, technical help, correction and an unresolved-variance record, but it cannot itself create sovereignty or a power of punishment, confiscation or adjudication.
  • The proposal was circulated to the RPD list on 26 September 2014 and is marked Withdrawn in AFRINIC’s archive. The RPD message and archive also preserve different identifiers, a discrepancy that remains unresolved.

When eight addresses started a clock

Imagine the ordinary provisioning event at the centre of the proposal. An AFRINIC Resource Member assigns a /29 to equipment in its own network or to a customer site. A /29 contains eight IPv4 addresses. It is not an immense block reserved for a rare transaction; it is small enough for the proposed rule to reach routine operational work. At the moment of assignment, the member’s customer ledger and network plan already contain facts about the block. The proposal would have required those facts to travel into AFRINIC’s WHOIS database, in documented form, no later than seven business days after the assignment.

That timetable gave the proposal its practical force. It converted a general expectation of accurate records into a measurable obligation with a threshold, a trigger and a deadline. The record mattered because other operators could need an administrative or technical contact when routing, security or abuse questions arose. It also mattered to the allocation system: registered assignments could be treated as evidence that previously issued address space was being used when a member sought more. A customer record was therefore no longer merely an internal provisioning note. It became part of a shared evidentiary infrastructure.

The proper response to a missing entry follows from that evidentiary purpose. The registry may identify the exact absent or inconsistent row. It may ask for the source assignment record, notify an authorised member contact, preserve the time of observation and allow correction. What it may not do is turn absence in its own ledger into a judgment that the assignment never happened, that the resource was abandoned or that a private institution may confiscate it.

Within the first practical step of the proposal lies the decisive institutional line: a recordkeeping rule can produce evidence and accountability, but a record is not a court order and the lack of one is not a sentence.

The proposal titled Mandatory requirements for registering assignments and sub-allocations records a submission date of 22 September 2014 and names Jean Robert Hountomey as author. The PDWG co-chairs, Seun Ojedeji and Adam Nelson, circulated it to the RPD list on 26 September as a new proposal. Circulation proved that a proposal had entered public discussion. It did not prove endorsement, consensus, ratification or implementation. AFRINIC’s archive now labels the proposal Withdrawn. The available record does not establish when it was withdrawn, who initiated that result or why.

Even the identifying label resists false neatness. The RPD announcement calls the instrument AFPUB-2014-GEN-003-DRAFT-01. AFRINIC’s archive calls it AFPUB-2014-GEN-001-DRAFT-01. Both labels belong in any faithful account. There is no basis here for selecting one as the legally correct identifier or silently rewriting the two records into agreement. The mismatch is itself a small example of the article’s larger point: registry information can be valuable, even authoritative about what a registry published, while still containing discrepancies that demand preservation rather than invention.

What the proposed record had to contain

The proposal was not vague about the core object. It sought to replace permissive wording in section 8(b), changing “will be” to “must be”, and to say that allocations and assignments had to be registered in an AFRINIC database. It also proposed a new section 9.7 for mandatory assignment registration in the IPv4 allocation policy. Because the instrument was withdrawn, these are descriptions of proposed text, not claims about a binding rule.

For the assignee record, the proposal listed inetnum, netname, descr, country, admin-c, tech-c and org. It also captured any other mandatory information required by an AFRINIC policy. The precision matters. inetnum identifies the address range; the other attributes situate the assignment through names, description, country and administrative, technical and organisational references. The proposal’s field list should not be inflated with later conventions or modern data elements. Its design was anchored in the WHOIS object it described at the time.

Every assignment equal to or larger than /29 would have fallen within the rule, whether the assignment served the member’s own network or a customer. The deadline was no later than seven business days after assignment, not seven calendar days and not an indefinite period measured from discovery or audit. The proposal also said registration information had to remain correct. Together, those elements would have created two kinds of work: a prompt initial submission and continuing maintenance as contact or descriptive facts changed.

Residential service required a different representational choice. The proposal described registering address blocks used by equipment or customer service areas and required netname and descr to signal residential use. That accommodation did not require a public row naming every household. Its purpose was to make the use of the block legible without pretending that a conventional business-customer object was appropriate for each residence. This was an effort to preserve operational value while limiting needless exposure.

Commercial sensitivity received a related treatment. The proposal acknowledged that members or customers might be reluctant to publish certain information. Sensitive details could be supplied privately to AFRINIC for audit under a confidential agreement. In the public object, fields other than netname and descr could reuse the member’s own information. The member would then carry responsibility for handling issues associated with the block. The arrangement was not a complete privacy regime: no confidentiality agreement, audit protocol, data-security standard or liability rule is established here. But it was a genuine attempt to distinguish what the public needed for contact from what the registry might inspect privately.

These details made the proposal more than a declaration in favour of tidy data. It tried to define the operational path by which a customer assignment became visible, attributable and countable. A network seeking additional IPv4 space could point to registered assignments as utilisation evidence. An operator investigating a technical problem could use the published contact chain. A security or abuse inquiry could start with an accountable member even where the customer’s sensitive details were not displayed.

Transparency in a further-address request would rest partly on the correspondence between the member’s account and the registry’s public objects.

That architecture offers real benefits. It also concentrates meaning in the database. Once an entry is used for contact, utilisation and future allocation decisions, the temptation is to treat it as conclusive about every question associated with the addresses. The proposal needed a rule for resisting that temptation. Instead, its most consequential language encouraged it.

The leap from evidence to sentence

The proposed amendments said that unregistered assignments, allocations and sub-allocations would be considered “invalid”. They also claimed that AFRINIC staff could conduct “any process”, following “approbation by the community”, to “reclaim” resources associated with missing registration. These few words carried far more institutional weight than the detailed registration fields. They moved the instrument from describing what a member should record to suggesting what could be taken away.

The first problem is semantic. An absent WHOIS object establishes one fact at a particular time: the expected public row was not found. It may indicate that the member failed to submit an object. It may reflect a rejected update, an incorrect field, a delayed correction, a mismatch between two records or some other unresolved cause. The absence does not, by itself, establish that no assignment occurred. It says nothing conclusive about whether addresses were routed, used or abandoned. It does not establish unlawful conduct, fraud, ownership, fault or a disappearance of rights.

Calling the row “invalid” cannot make all those separate propositions true.

The second problem is institutional. AFRINIC is a private technical bookkeeper and coordinator. It is not a sovereign, government or legislature. It has no regulatory jurisdiction merely because it maintains a regional database. It is not a police force or prosecutor; it has no inherent punishment or confiscation power; and it is not a court capable of adjudicating legal rights. Its recognition of an entry can have practical network consequences because participants rely on coordinated records. That practical importance does not convert database administration into public-law authority.

Nor can a discussion forum supply the missing power. Community participation can help refine a technical rule, expose operational problems and build cooperative legitimacy. It can decide what records a voluntary coordination system should request. But “approbation by the community” cannot create sovereignty, jurisdiction or coercive authority that no law delegated. A vote does not turn staff into a confiscating body. A mailing-list consensus, even if one had been established here, could not erase the distinction between an operational discrepancy and a legal determination.

The proposal’s reference to “any process” made the problem sharper because it left the process unbounded. The text did not specify what a notice must contain, how long a member would have to correct the record, how rejected updates should be treated or what evidence standard would apply. It did not identify a decision-maker, require written reasons, create an appeal or provide independent review. It did not define the sequence or limit of a reclaim procedure. Absence of those provisions from this proposal does not prove that no other instrument addressed procedure.

It does mean this instrument cannot itself be cited as supplying the missing safeguards.

A severe consequence needs more than strong recordkeeping language. If a legal-rights remedy is thought necessary, the competent authority must exist under applicable law. It must have jurisdiction, a defined procedure, evidence, notice, a hearing, reasons and a route to review. Those are not decorative additions to a database rule. They are the conditions that distinguish an administrative assertion from a lawful decision. No private registry can acquire them by writing the word “reclaim” beside an unregistered object.

This is not an argument for passive recordkeeping. A registry can be demanding about the quality of the evidence it maintains. It can timestamp discrepancies, ask for source records, insist on complete fields, contact authorised representatives, provide a correction period and document what remains unresolved. It can make the history legible to those who rely on it. The discipline can be exact without claiming that technical recognition is title or that non-recognition is forfeiture.

A proposal, a support document and an unresolved process question

The mailing-list discussion also exposed uncertainty about the instrument’s form. One participant, Paulos Nyirenda, argued that an amendment should be presented as a full amended policy rather than as isolated changes, so readers could evaluate the complete text and its history. That objection was about intelligibility and process: a proposed insertion may look clear by itself yet interact with provisions that are invisible when the base document is not shown.

Another participant, Alain Aina, distinguished a policy from a support document and argued that merging the two was not a good idea. He questioned whether community approval was needed before relying on RSA section 4 and suggested updating the support document accompanied by an awareness period. The proposal’s author then asked how best to proceed along the suggested support-document and awareness route. These exchanges show that participants were testing both substance and procedural vehicle. They are arguments made in the discussion, not legal rulings about the RSA or a formal decision on what the policy process required.

The distinction mattered because operational guidance and punitive claims do different work. A support guide can tell a member how to construct an inetnum object, which fields to populate and where to seek help. A policy can state a shared expectation and the terms on which resource administration proceeds. Neither format, merely by being labelled or approved, creates sovereign authority. The form question is still important, however, because members should be able to see whether a document is teaching a procedure, defining a recordkeeping condition or purporting to authorise an adverse act.

The public record does not establish a second draft, a complete amended base policy, a final consensus assessment, a last call, Board ratification or an implementation notice. The archive’s affirmative description is Withdrawn. That status prevents the analytical mistake of treating the proposal’s most forceful words as an operative power. It also leaves open questions: the date and reason for withdrawal, the person or body responsible for the step and the procedural route are not established.

The withdrawal does not make the proposal irrelevant. Drafts are valuable evidence of institutional design choices. This one makes unusually clear how a modest recordkeeping objective can carry an expansive theory of consequence. Its concrete threshold, deadline and field list show the appeal of precise accountability. Its vocabulary of invalidity and reclaim shows how quickly evidence administration can be mistaken for jurisdiction. Reading both halves together is more useful than either celebrating the data rule or dismissing it because it did not take effect.

The record is useful precisely because it is not a verdict

WHOIS information can be a starting point for action. When packets follow an unexpected route, an operator may need the technical contact associated with an address range. When abusive traffic is reported, an investigator may need an accountable organisation or mailbox. When a business considers connectivity or infrastructure risk, public registration data can support due diligence. When a registry evaluates a request for more IPv4 addresses, documented assignments can help test the member’s account of utilisation.

Each use depends on taking the record seriously. None requires pretending the record is self-proving. The listed organisation may not reveal a present downstream operator. A public contact may not show the complete contractual chain. An address object does not alone establish who controlled equipment at a particular moment, whether a mailbox was monitored or who was responsible for specific traffic. The record supports inquiry; it does not end it.

That limited status is a strength, not a weakness. Evidence becomes more trustworthy when its scope is explicit. A timestamped accepted update reliably shows what was submitted and recorded. An error response reliably shows that a particular submission was rejected for a stated reason. A correction trail shows how the object changed. None needs to carry conclusions about title, legality or culpability. By refusing those extra conclusions, the registry can preserve information that operators actually know how to use.

The 2014 proposal’s customer records would have served as compliance infrastructure in this exact evidentiary sense. They would connect private provisioning to shared accountability, allow utilisation claims to be checked and maintain a route for operational contact. Once the proposal instead attached the possibility of invalidity and reclaim, the database acquired a second imagined role: not only evidence about the network, but an instrument for deciding what rights survived. That second role had no lawful foundation in the proposal.

The correct line is therefore neither laissez-faire nor punitive. Members should not be free to invoke utilisation that they refuse to document. The registry should not be free to treat its own incomplete view as conclusive guilt. Between those positions lies demanding administration: specify the expected row, obtain the smallest relevant proof, correct the data and preserve whatever cannot be resolved. That is how an address register remains useful without becoming a tribunal.