Summary

  • Draft 2 proposed a general six-month retention period for personal data, a financial-record exception lasting up to twelve months after an agreement ended, and historical retention for allocation or assignment data that had been public for at least one month.
  • It would have limited applicant-derived, user-identifying data to no more than one quarter of the users receiving the applicant’s address space, an unusually concrete restraint on the evidence a registry could demand.
  • Before personal data went to another country, the proposal required a public assessment of five matters and a public transfer register, but it left the decision standard, approving authority, legal basis, review process and redaction method unspecified.
  • AFRINIC-17 recorded no consensus on 28 November 2012. The archive records withdrawal the next day, while AFRINIC’s annual report places the withdrawal in December; neither source supports adoption or implementation.
  • The durable answer is two-layered: a narrow number-resource rule limiting what the registry may require from an applicant, and a separate corporate privacy programme governing what AFRINIC keeps, deletes, secures, transfers and discloses after receipt.

A short clock for a large institutional question

Six months sounds admirably definite. Under the second draft of the Regional Internet Registry Privacy proposal, personal data held in connection with number-resource administration would have had a general retention period of six months. Data necessary for financial purposes, such as billing, could remain for as long as twelve months after the end of a Registration Service Agreement. Allocation or assignment data that had already been public for at least one month could be kept for the historical record. Transfers to another country needed a publicly available assessment, followed by an entry in an anonymously accessible transfer register.

Those concrete rules made Draft 2 easy to read and difficult to administer. The text did not say when the six-month clock began, whether a later use reset it, which copies counted, how deletion would be proved, or what happened when a legal obligation required a different period. The cross-border assessment listed five relevant considerations but did not identify the person who would decide, the result that would permit a transfer, the relationship to public-law authorisation, or the information that could safely be published.

At AFRINIC-17 in Khartoum on 28 November 2012, the official minutes record objections both to an unclear problem statement and to the attempt to address through policy matters governed by Mauritius law. The co-chair found no consensus and returned the proposal to the mailing list. The archive then records its withdrawal. That sequence matters: Draft 2 was a proposal that exposed a real privacy problem, not an operating rule.

The central distinction is between two control planes. A number-resource policy can limit the evidence a private registry asks an applicant to produce for a defined registry decision. That is a proper protection against an administrative chokepoint reaching into customer records. But the retention, deletion, security, disclosure and international processing of data already received are duties of the private corporation as data controller. They require applicable law, responsible officers, systems, security controls, exceptions and remedies.

A participant forum cannot turn those corporate duties into sovereign legislation by writing precise numbers into a proposal.

What Draft 2 actually proposed

The AFRINIC archive titles the proposal “Regional Internet Registry Privacy” and identifies it as AFPUB-2012-GEN-002-DRAFT-02. It lists S. Moonesamy as author and 16 November 2012 as the submission date. An archival inconsistency should be kept visible: the page’s unique-identifier field prints DRAFT-01, even though its title, history, meeting material and annual report identify Draft 2. The cause is not established. The archive describes the second draft as containing minor revisions, but the first draft’s actual clauses are not available in the source record considered here, so no reliable line-by-line comparison can be made.

Draft 2 defined personal data in relation to an identified or identifiable natural person. Identification could be indirect, including by an identification number or by physical, physiological, mental, economic, cultural or social factors. This was a broad functional definition, but it did not inventory AFRINIC’s datasets or establish which particular records fell within it. Applicants, resource holders and the natural people described in submitted material are distinct groups; the proposal did not map every data class to each of them.

The draft began from familiar minimisation language. Collection and transfer were to be confined to personal data directly relevant and necessary for specified, explicit and legitimate purposes. Information about whether data were adequate, relevant and not excessive for the collection or transfer purpose would be available to anyone participating in the AFRINIC-region Policy Development Working Group. That clause referred to information about an adequacy assessment. It did not expressly require disclosure of the personal data being assessed.

The sharpest applicant-facing rule was numerical. AFRINIC would not collect from a number-resource applicant personal data capable of identifying more than one quarter of the users to whom the applicant had allocated address space. One quarter was an absolute maximum, not a recommended sample size and not a statement that collecting anything below 25 per cent was automatically proportionate. The denominator’s timing was unstated. The proposal did not explain whether the rule concerned a sample, all data indirectly capable of identifying people, or a changing population of users. Nor did it state why one quarter was the right ceiling.

Section 3.1 supplied the memorable clock: six months for personal data. It then created two materially different qualifications. Personal data necessary for financial purposes, such as billing, could be held for up to twelve months after the end of a Registration Service Agreement. Personal data published for number-resource allocations or assignments could be retained for the historical record if it had been publicly available for at least one month. The first exception had a terminal maximum tied to the end of a contract. The second had an entry threshold but no stated final expiry.

Section 3.2 addressed transfers to another country. Before a transfer, there had to be a publicly available assessment covering five matters: the nature of the data; the purpose and duration of processing; the countries of origin and final destination; the law in the destination country; and the rules and security measures observed there. Section 4 added a personal-data transfer register. It would record the transfer date, the nature of the data, the processing purpose, and the countries of origin and final destination, with those countries paired in the proposal’s lettering.

The register was to be published through a service anonymously accessible over the internet. Financial-purpose personal data was exempt from publication.

This was a register of transfer metadata, not an express order to publish raw records, names or customer lists. Yet “nature of the data” could be described at many levels of detail. The proposal did not specify the safe granularity. A broad label might tell the public too little to make transparency useful; a narrow one might disclose facts about people, security or business relationships. That tension was left unresolved.

Section 5 required notice to the Resource Policy Discussion mailing list within one day after detection of a personal-data leakage, including an explanation of its nature and extent. The draft did not define detection, the risk threshold, the investigation stage at which a notice would be accurate, a lawful reason for delay, redaction, direct notice to affected people, or responsibility for issuing the message. One day was exact. The process around it was not.

Finally, the proposal excluded data publicly available through, for example, a service anonymously accessible over the internet from its restrictions. It did not comprehensively define how data acquired public status, whether publicity produced by the registry itself qualified, or what happened if previously public data was later corrected or removed. This exclusion and the historical-record exception together made the treatment of publicity pivotal, yet neither supplied a complete lifecycle rule.

The one-quarter rule belonged at the applicant interface

The proposal’s strongest insight was that privacy risk can arise before a corporation decides how long to keep a file. It begins with the demand. A regional internet registry is a dependency for operators seeking or maintaining number-resource records. That position can make an evidence request difficult to refuse even though the registry is only a private coordinator. If a hostmaster asks for customer-level material when organisation-level evidence or aggregate information would establish the relevant fact, the request expands privacy, security and compliance exposure without improving thin registry coordination.

The one-quarter ceiling was an attempt to place an outer wall around that reach. Its empirical basis is unknown, and the number by itself was too crude to decide necessity. Even so, its regulatory object was intelligible: what an applicant could be compelled to disclose as part of a number-resource decision. That is precisely where a number-resource rule can operate. It can require the registry to state the decision at issue, identify the fact each requested item proves, explain why less intrusive evidence does not suffice, and refuse customer-level collection where aggregate or organisational proof answers the question.

This point is reinforced by later operator correspondence hosted by the Number Resource Society. In a 2021 dispute, Cloud Innovation objected that a private AFRINIC demand for monitoring or customer-use information lacked an identified basis in the Registration Service Agreement and risked reaching user data at continental scale. That correspondence is the position of a party in a later dispute. It does not establish what motivated the 2012 author, whether Draft 2 was ever used, or whether any conduct in 2012 occurred.

Its relevance is narrower and still important: it demonstrates the kind of operator concern that an applicant-facing minimisation rule is designed to answer.

A good evidence rule would be more exact about purpose and less enchanted by a fixed percentage. It would begin with the legitimate registry functions: preserving the uniqueness of number records, recognised holdership, accurate status, usable role contacts, security metadata and continuity. It would then ask what minimum evidence is necessary for the particular decision. If a company’s legal existence, network plan and aggregate utilisation can establish eligibility, records naming thousands of downstream users should not become the default. A maximum does not convert every lesser demand into a necessary one.

The difference is not semantic. Overcollection imposes immediate costs on the applicant: extracting records, reviewing them, obtaining legal advice, securing transmission, tracking copies and accepting the possibility of later exposure. It also imposes costs on AFRINIC, which must classify, secure, restrict, correct and eventually delete what it receives. Data that is never collected cannot be leaked, misused by an insider, swept into discovery or transferred through an unseen vendor. A narrow policy at the intake gate can therefore reduce risk on both sides.

But the applicant-facing rule must not mutate into a power to supervise users. AFRINIC’s technical position and control of registry records give it practical leverage, not legal jurisdiction over the customers of resource holders. It is not a sovereign, legislature, regulator, police force, prosecutor, punisher, confiscator or adjudicator. It may ask for proportionate evidence that a registry fact requires; it may not use dependence on its database to monitor, rule or punish networks and their users.

Any privacy remedy that impaired number resources, routing-security functions or reverse-DNS service without competent law and independent adjudication would reproduce the very authority problem that minimisation is meant to constrain.

The six-month rule crossed into corporate data governance

Once AFRINIC receives evidence, the institutional question changes. The issue is no longer simply what an applicant must provide. It becomes which legal entity controls the record, why it keeps it, where it is stored, who can see it, which processor handles it, how long each copy remains necessary, what legal hold applies, how deletion is verified and what remedy exists for error or misuse. Those are corporate privacy responsibilities. In 2012 AFRINIC Ltd was a private company established in Mauritius, not a public regulator for the continent.

The Mauritius Data Protection Act 2004 provided an existing public-law layer. Its official text applied to a controller established in Mauritius processing data in the context of that establishment and required observance of statutory data-protection principles. Its fifth principle was purpose-based: personal data should not be kept longer than necessary for the purpose. Its eighth restricted transfer to a third country unless adequate protection existed. Official controller guidance called for defined retention schedules, routine purging when no good reason remained and responsibility for deletion.

On transfers abroad, it described written Commissioner authorisation, an adequacy inquiry and narrow alternatives.

That legal context does not decide every question about AFRINIC in 2012. The available material does not establish the company’s registration status, every applicable provision, each record category or any Commissioner decision concerning Draft 2 or AFRINIC. It is not a complete legal opinion. It does show why a universal six-month number could not stand alone as a corporate retention system. The statutory principle turned on necessity for purpose; the proposal imposed a single duration without mapping purposes, legal bases or record classes.

The missing start event is particularly serious. Does six months begin when an applicant uploads a document, when a hostmaster views it, when a decision is made, when a resource is issued, when an appeal ends or when the record is last used? If the same information supports two purposes with different end points, does one clock govern both? Does a correction restart the period? What about a backup that cannot be selectively erased immediately, a paper copy, an email attachment or a processor’s replication? Draft 2 answered none of these questions. No actual system, backup, vendor or deletion method can be inferred from the silence.

A flat limit can fail in both directions. Six months may be too long for an identity document needed only to verify a fact during a short review. Keeping it for the rest of the period would add risk without purpose. Six months may also be too short for material legitimately needed to answer an unresolved dispute, a fraud investigation, a statutory obligation or an audit. Whether either situation existed at AFRINIC is not established. The point is architectural: without a purpose-and-record map, a duration cannot reliably tell a controller when deletion is lawful or necessary.

Verification matters as much as the date. A serious retention schedule identifies the record owner, system, processor, location, access group, trigger, period, exceptions and deletion evidence. It explains how holds are approved, recorded, reviewed and released. It distinguishes active systems from archives and backups. It establishes what happens to derived records and indexes. The proposal supplied none of that machinery. A participant-approved sentence could express an objective, but it could not make the objective operational by itself.

This is where institutional modesty improves privacy. A number-resource community does not need to pretend to legislate the company’s internal systems in order to demand that the company behave responsibly. The policy can bind the evidence gate: no irrelevant customer data, a stated purpose for every request, proportionate alternatives and a clear review route. The corporation must then publish a privacy programme explaining data classes, legal bases, retention triggers, transfer safeguards and accountable roles, subject to applicable law and competent public institutions. Each instrument does the work it is suited to do.

Twelve months for finance was an exception without a map

The financial exception was more carefully anchored than the six-month rule because it linked the period to the end of a Registration Service Agreement. Personal data necessary for financial purposes, such as billing, could be kept for up to twelve months after that point. The words “necessary” and “up to” matter. They did not command a full year for every financial record. Nor did they establish that twelve months was sufficient for every accounting, tax, fraud, dispute or statutory obligation.

The source record does not establish the lawful retention period for each such class. It would be a mistake to fill that gap with later law, contemporary practice or assumptions about Mauritian accounting. It would also be a mistake to treat the proposal’s number as an exemption from public law. A private policy could not erase a statutory duty to retain a particular record, create a lawful basis that did not otherwise exist, or authorise premature destruction.

The phrase “such as billing” also left the category open. A payment record, invoice, bank detail, correspondence about a disputed balance and identity evidence used during contracting might all touch finance while serving different purposes and carrying different risks. A useful schedule would classify them separately. It would retain the minimum necessary fields rather than a whole application file simply because one page related to payment.

There is nevertheless a sound intuition behind the exception: contract closure can be a meaningful retention trigger. The error was treating one trigger and one maximum as enough. A mature programme would map the agreement end date to each record class, then overlay applicable obligations and documented holds. It would state who approves exceptions and how stale copies are purged. The maximum would be a result of that analysis, not a substitute for it.

The public-history exception needed a lifecycle

Draft 2 allowed allocation or assignment personal data to remain in the historical record after it had been publicly available for at least one month. That rule recognised a real registry interest. A useful public record may need to show the continuity of number-resource status, role contactability and changes over time. Erasing every prior fact can make a registry less accurate and less useful to operators investigating incidents, routing history or administrative responsibility.

Yet prior publicity does not make every piece of personal information harmless forever. The proposal did not identify which fields belonged in a durable public history, how a correction would propagate, whether a person could object, when a role contact should be replaced, or when redaction should outweigh historical value. It did not state how the one-month threshold would be proved. Nor did it provide a terminal review point. “Historical record” was a purpose label, not a full public-interest test.

Privacy-safe registry design can preserve the useful record while reducing personal exposure. Public surfaces can show resource status, recognised holder, organisational role, role-based contactability, relevant security metadata and uncertainty. Private evidence used to establish those facts need not become public. Customer lists, identity documents and sensitive supporting material can remain outside the public layer. Corrections can be logged without displaying superseded personal details indefinitely.

That distinction also prevents opacity from masquerading as privacy. A registry must remain intelligible enough for networks to know who holds a resource, how to contact an appropriate role and whether a record is current or disputed. The answer to overcollection is not a blank database. It is a thin, purposeful public record backed by protected evidence and visible correction rules. Draft 2 pointed toward minimisation but did not specify this separation.

A public cross-border assessment was not an approval system

The five-factor transfer assessment was Draft 2’s most ambitious transparency device. It asked about the nature of the data, the purpose and duration of processing, origin and final destination, destination-country law, and the rules and security measures observed there. These factors closely resembled those in official Mauritian controller guidance. Textual similarity, however, does not establish drafting origin, the author’s intent or legal sufficiency.

The proposal made the assessment public but did not say who prepared it. A privacy officer, management, the board, outside counsel, a vendor or the participant forum could reach different conclusions and carry different accountability. It did not identify who approved the transfer or what outcome the five-factor review had to produce. It did not say whether the assessment was updated when a vendor, destination, law, subprocesser or security measure changed. It did not provide a review interval or an emergency process.

Most importantly, public availability was not the same thing as public-law authorisation. Official guidance described written Commissioner authorisation, an adequacy inquiry and narrow alternatives for international transfers. Draft 2 did not reproduce that mechanism or map its public assessment to those alternatives. Nothing in the proposal established that publication would satisfy, replace or override the law. Conversely, nothing here establishes whether any actual AFRINIC transfer occurred, where it went, what legal basis it used or whether any approval existed.

Transparency still has value. Operators face real costs when they cannot tell which jurisdictions, vendors and remedies surround sensitive evidence. A privacy-safe transfer notice can identify the controller, processor, destination, purpose, legal basis, safeguards, approval date, review date and route for complaint. It can do so without exposing raw personal information, secret security architecture or commercially sensitive details. The public explanation should be the output of a competent internal and legal process, not a substitute for one.

The proposed public register had the same strengths and weaknesses in concentrated form. Transfer date, data nature, purpose, origin and destination could reveal patterns relevant to accountability. But the financial-purpose exemption would remove some transfers from public view, and the unspecified granularity of “nature” created a disclosure risk. A safe register needs a classification scheme and redaction standard. It should say enough to make oversight meaningful while protecting the people whose information prompted the entry.

Cross-border data control is also not sovereignty over the people described in the records. Technical custody in a particular server or contractual access by a vendor does not confer political jurisdiction. AFRINIC’s responsibility arises because the private company controls processing in a legal and operational environment. Its participant community cannot manufacture sovereign power over applicants or users by voting on a transfer notice. The correct response is accountable corporate control under law, combined with a narrow rule preventing needless intake.

A one-day leakage notice needed risk and response machinery

The requirement to notify the Resource Policy Discussion mailing list within one day of detecting a personal-data leakage had an appealing urgency. Slow disclosure can compound harm and deny affected people the chance to protect themselves. But a public list is not automatically the right first recipient, and speed without a response structure can produce inaccurate or harmful disclosure.

“Detection” can mean an automated alert, a preliminary report, confirmation by an investigator or a completed assessment. “Leakage” can range from an email sent to the wrong recipient to a large unauthorised extraction. The draft did not define either term. It did not specify a severity threshold, direct notice to affected people, contact with competent authorities, preservation of evidence, lawful delay, staged updates or redaction. Requiring the nature and extent within one day could force a company to publish an uncertain estimate while an investigation was still establishing scope.

A proper incident programme separates audiences and decisions. Affected people need timely, useful advice. A public authority may require information in a particular form and period. Operators may need a continuity or security notice. The public may deserve an account that is accurate and safe. Investigators need protected evidence. None of these responsibilities gives AFRINIC punitive authority over resource holders. An incident must not become a pretext for resource revocation or technical impairment absent competent law and independent adjudication.

Again, the participant forum could articulate an expectation of transparency without pretending that a one-sentence deadline supplied the necessary machinery. The company needed named incident roles, escalation criteria, legal review, investigation capacity, protected communication channels and update rules. The proposal’s exact day exposed the absence of those surrounding decisions.

The strongest case for keeping all the limits in policy

The most persuasive defence of Draft 2 starts with distrust of internal promises. Applicants pass through a private administrative gate to obtain or maintain records essential to network operation. A privacy statement written by management can be changed by management. A retention schedule hidden inside the company offers little leverage to an operator asked for intrusive evidence. If bottom-up policy defines the evidence gate, the argument runs, bottom-up policy should also impose binding limits on collection, retention and transfer. Public assessments and registers would give members a means to detect expansion and contest it.

This case is strongest where the applicant confronts the hostmaster. A rule that merely asks AFRINIC to be reasonable would be too weak. Applicants need a durable entitlement to demand relevance, necessity and proportionality. They need to know the registry decision being made, the fact a document is meant to prove, the less intrusive alternatives considered, the maximum burden and the route to review. A concrete ceiling can stop “just in case” collection from becoming normal.

The defence also correctly observes that corporate and applicant concerns overlap. What AFRINIC promises about deletion affects whether an applicant is willing to submit evidence. A transfer abroad may change the applicant’s risk. A public incident notice may reveal whether stewardship has failed. Drawing an institutional boundary must not become an excuse for management secrecy.

But the answer is not to collapse the two planes. A six-month clock without data classes or legal exceptions is not more binding in practice simply because participants support it. It may command deletion that is too late for one purpose and too early for another. A public assessment without a decision standard or competent approval is not a transfer safeguard. A public register without redaction rules can create another privacy exposure. A one-day notice without incident roles can replace silence with confusion.

The better response preserves the applicant’s leverage while locating each duty in the instrument capable of performing it. Number-resource policy should prohibit irrelevant demands and require a contestable, recorded justification for any sensitive evidence. Corporate governance should turn applicable law into a data inventory, retention schedule, access model, deletion proof, transfer approval and incident plan. Public reporting should expose commitments, aggregate performance, transfer metadata and material incidents at a safe level. Competent public authorities and courts retain their legal roles.

No community vote converts AFRINIC into any of them.

What the no-consensus outcome does—and does not—prove

The official AFRINIC-17 minutes record Subramanian Moonesamy presenting Draft 2 remotely. Yaovi Atohoun is recorded as questioning the clarity of the context and problem and pointing to the policy-proposal format. Douglas Onyango is recorded as arguing that privacy was governed by the law of incorporation, that AFRINIC was bound by Mauritius law and that the policy lacked legal authority to address the issue. Adiel Akplogan is recorded as saying privacy issues should be handled legally and that AFRINIC’s privacy policy aligned with Mauritius law, while acknowledging privacy aspects in registry-held data.

These are summaries, not a verbatim transcript or a complete record of every remote contribution, intervention or show of hands. They prove what the official minutes recorded, not that any speaker supplied a final legal opinion or judicial ruling. AFRINIC’s own publication of the minutes proves its record of the event; it does not confer legitimacy on the proposal or conclusively settle the institutional boundary.

The co-chair declared no consensus and deferred the proposal to the mailing list. The archive says the author withdrew it on 29 November 2012. The 2012 annual report lists Draft 2 among five proposals that failed to gain consensus at AFRINIC-17 and among proposals withdrawn by their authors, but describes the withdrawal month as December. The day-month discrepancy should remain unresolved. It may reflect reporting convention, publication timing or something else; the available material does not say.

No consensus and withdrawal do not prove that privacy was unimportant, that every clause was substantively wrong or that no useful idea could be recovered. They do prove that this text was not adopted through that process. There is no basis here to claim it was ratified, implemented or used to govern later conduct. There is likewise no basis to infer the author’s motive, institutional sponsorship, legal advice, costs, systems, transfers, deletion practices, leaks or effects.

The outcome is better understood as a design warning. The proposal bundled an applicant-facing limit with company-wide privacy administration. Participants could agree that overcollection was dangerous while disagreeing that a number-policy process was competent to set the company’s retention and international-transfer regime. Separating those questions would have made both more answerable.

A two-layer design that could survive contact with operations

The first layer should govern the registry interface. Every request for applicant data should name the number-resource decision and the fact the requested item is intended to prove. The registry should use organisation-level, role-based or aggregate evidence when it suffices. Customer-level data should be prohibited unless a defined, exceptional need is established under a reviewable rule. The policy should distinguish a maximum from necessity: even if one quarter remains an outer ceiling, AFRINIC must justify why any amount is proportionate.

That layer should also provide process protection. Applicants need notice of the request, the purpose, the fields sought, the retention information supplied by the corporation and the consequence of refusing. They need a chance to offer a less intrusive substitute, correct a misunderstanding and seek independent review. The registry must keep the record accurate and contactable without treating a dispute over private evidence as authority to punish, confiscate or adjudicate.

The second layer should govern corporate custody. AFRINIC should maintain a data inventory that identifies, for each record class, the purpose, legal basis, owner, system, processor, physical or cloud location, authorised access, retention trigger, duration, deletion method and proof. A six-month period may be appropriate for some records and wrong for others. The schedule must map statutory requirements and documented dispute or litigation holds before numerical ceilings are fixed.

For transfers abroad, the corporate record should identify the competent legal basis, any required public authorisation, destination, processor, safeguards, assessment owner, approval, review date and remedy. Public disclosure should present privacy-safe metadata, not protected evidence. Changes in destination, vendor, law or security measures should trigger review. The proposal’s five factors can inform the questions, but cannot substitute for approval and accountability.

Incident response should identify who receives alerts, who confirms scope, who preserves evidence, who decides notifications and how affected people receive useful information. Public notices should be accurate enough to support trust without disclosing additional personal or security-sensitive details. Timing should follow applicable law and risk, with documented reasons for any staged disclosure. A mailing-list notice can be one transparency channel, not the whole response system.

The public registry itself should remain thin but useful. It should show recognised holdership, status, organisational role contacts, relevant security metadata and material uncertainty. Supporting identity documents, customer lists and sensitive evidence should remain protected. Historical continuity should be preserved at the level necessary to understand the record, with correction, objection, replacement and redaction mechanisms for personal details.

Public accountability connects the layers without confusing them. AFRINIC can report the categories of data requests, use of exceptional customer-level demands, retention performance, overdue deletion, transfer destinations at a safe level, material incidents and corrective action. Applicants can test whether intake rules are being honoured. Directors, management and privacy officers can be held responsible for the company’s systems. Public regulators and courts can exercise the legal authority that a private coordinator lacks.

The economic case for precision

Institutional boundaries can sound abstract until an operator has to answer an intrusive request. Each additional record carries extraction, review, transmission, storage and security costs. Unclear demands delay number-resource decisions and can deter accurate updates. If applicants fear that every correction opens a demand for customer data, the registry’s own records may become less reliable.

Over-retention expands the surface for breach, insider misuse and legal discovery. Premature deletion can destroy billing, audit, dispute or continuity evidence. A single number chosen without a data map can therefore increase cost in either direction. Purpose-specific schedules reduce both forms of waste: dispose of what no longer has a good reason to exist, preserve what a competent obligation still requires and record the reason.

Opaque international processing prevents operators from assessing vendor and jurisdiction risk. Overbroad transparency can expose sensitive relationships or data categories. A redacted, structured transfer notice allows the company to disclose what accountability requires without publishing protected material. The design problem is not secrecy versus total publication; it is useful information versus avoidable exposure.

Uncertain registry governance is itself infrastructure exposure. Networks depend on accurate coordination records and stable administrative services. If privacy disputes are converted into resource impairment or unpredictable demands, the operational risk reaches customers who never joined a policy discussion. LARUS analysis of registry governance highlights that dependence, but does not establish any effect of Draft 2 in 2012. It supports the prudential point: thin, predictable administration reduces operational risk.

Clear separation also lowers the cost of legal uncertainty. Applicants should not have to guess whether compliance with a private policy satisfies Mauritian law; it may not. Corporate officers should not have to treat a participant vote as a substitute for legal advice or regulator approval. A precise interface rule and a competent corporate privacy programme let each actor know which obligation comes from where.

Unknowns that should remain unknown

The record leaves consequential questions unanswered. It does not establish the exact language of Draft 1 or the minor revisions that led to Draft 2. It does not explain why the archive’s unique-identifier field says DRAFT-01. It does not identify the incident, evidence or empirical reasoning behind six months, twelve months, one month or one quarter.

There is no established start or reset event for the six-month clock. There is no inventory of data classes, systems, processors, backups, paper files, vendors or deletion methods to which it would have applied. The lawful periods for financial, tax, employment, fraud, dispute and security records are not supplied. No actual deletion, transfer, register entry, leakage or affected person is established.

For cross-border assessments, the preparer, approver, publisher and reviewer are unknown. So is the outcome necessary to allow a transfer and its relationship to Commissioner authorisation or statutory alternatives. The intended detail of the transfer register and leakage notice is unknown. The complete meeting debate and remote participation record are unavailable. The official sources conflict on whether withdrawal occurred on 29 November or in December 2012.

These gaps are not invitations to speculation. They define what a future inquiry should seek: the first draft, mailing-list discussion, staff assessments, legal opinions, author explanation and any Commissioner record. Later material may illuminate how institutions evolved, but it cannot be used backwards to assert that Draft 2 was adopted or operational in 2012.

The boundary Draft 2 helps us see

Draft 2 deserves credit for locating a vulnerability that registry administration can otherwise conceal. A private bookkeeper may need evidence to maintain accurate number records, but it does not need jurisdiction over the people who use a network. A rule limiting applicant-derived user data was therefore not alien to number policy. It was a protection at the very gate where practical leverage could produce overcollection.

The proposal became less convincing when it moved from the gate to the company’s data estate. Six months, twelve months, a month of publicity, five transfer factors, a public register and a one-day notice were precise enough to look complete. They were not a substitute for classification, purpose, legal basis, approval, security, deletion, redaction and remedies. Precision in a number is not the same as completeness in an institution.

The durable settlement is neither corporate discretion nor community sovereignty. It is constrained coordination. The registry asks only for evidence tied to a defined number-resource decision and accepts less intrusive proof when it works. The private company then handles what it receives through a law-governed privacy programme with accountable officers and auditable controls. Public reporting makes the boundary visible without exposing protected records.

That design protects applicants more effectively than an undifferentiated privacy policy because it addresses the coercive moment of collection. It protects data subjects more effectively than a universal clock because it governs the whole lifecycle. And it protects internet coordination by refusing to turn privacy disputes into a new source of private regulatory or punitive power. Draft 2 did not win consensus, but its failure clarifies the question any successor must answer: what must the bookkeeper know, and who lawfully governs what the company does once it knows it?