Summary

  • LACNIC’s authoritative Spanish Policy Manual v2.21 requires a working abuse contact, provides an initial fifteen-day validation period and a further fifteen-day escalation period, and defines missed validation as noncompliance. It does not state that MiLACNIC access will be blocked.
  • LACNIC’s live operational instructions do state that access to MiLACNIC is blocked until validation. They offer three ways to cure the condition, but do not enumerate the portal functions withheld or preserved.
  • An earlier version of proposal LAC-2018-5 explicitly contained a failure-to-comply section with a MiLACNIC block, NIR-equivalent measures and exceptions. The final version’s own change note says that section was eliminated.
  • Abuse-contact validation is useful. The governance defect is narrower: a consequential administrative gate should have a versioned public record linking its authority, trigger, scope, exceptions, cure, review route and supersession history.

The sentence after the rule is on another page

Read LACNIC’s current policy manual to the end of section 12.4 and the sequence is orderly. Every resource using the registry system must carry an abuse-c attribute. Its mailbox must be valid, monitored and attended. It must accept reports and supporting material without forcing every sender into a bespoke web form. The holder receives an initial fifteen days to validate. If that attempt fails, the process escalates through other available contacts for a further fifteen days. LACNIC validates at least twice a year and when the relevant contact attributes are created or changed.

Then comes the finding: an organization is noncompliant if it has not validated within either period. The next numbered section is not a consequence table. It is the route for reporting suspicious behaviour or failure to attend abuse cases so that LACNIC can initiate revalidation. The manual says nothing there about losing access to MiLACNIC. LACNIC Policy Manual v2.21, authoritative Spanish PDF English translation

The operational page supplies the missing sentence. Its title is “How to Validate Your Abuse Contact to Unblock Access to MiLACNIC.” Its body tells an organization that, at this stage, access to MiLACNIC will be blocked until the abuse contact is validated. It then shows the user how to replace the contact with one already validated, request a validation message, or change the current email address. LACNIC’s MiLACNIC-unblock instructions

Both pages can be accurate. The problem is that they answer different halves of the same control question. One identifies the rule and the condition. The other identifies the gate and the cure. A member must join them unaided to learn what institutional act follows a missed validation.

An earlier draft knew that the consequence mattered

The omission would be less revealing if portal blocking had always been treated as a mere implementation detail. LACNIC’s own proposal history shows otherwise.

Earlier text for LAC-2018-5 included a separate section called “Failure to comply.” It said failure after the initial and additional periods would result in the blocking of MiLACNIC and equivalent measures in NIR systems for all resources associated with the organization. It also named exceptions: strictly contractual and payment matters, plus the ability to update the abuse contact so it could be revalidated and the portal unblocked. A warning screen and possible further action for continuing noncompliance were described as well.

That was not an accidental line in a tutorial. It was a proposed rule about the breadth of an administrative consequence. The final-version explanation then says that the “Failure to comply” section was eliminated. The text retained in the current manual defines noncompliance but omits the block, the NIR language and the exceptions. LAC-2018-5 proposal and version history

This history prevents two easy answers. It is not enough to say the help page merely paraphrases the policy, because it adds a consequence the final text does not state. It is also not enough to declare that the consequence therefore has no authority. A member agreement, service condition or other procedure may supply authority outside the five public records examined here. The evidence proves a documentary separation, not an unlawful act.

That narrower conclusion is the useful one. A consequence considered important enough to specify, delimit and debate in an earlier proposal now appears on an operational page without the same scope or exception record. The control survived in public; its policy explanation did not.

A reachable mailbox is a legitimate safety mechanism

An abuse contact is not decorative registry data. When phishing, malware, scanning, credential theft or other harmful traffic is traced to an address, a usable mailbox lowers the search cost of reaching somebody who can investigate. Requiring a human acknowledgement is also rational. An automated response proves that a mail server exists; it does not prove that a person monitors the queue or can route a report to the operator, customer or reseller with practical control.

LACNIC’s policy is careful about this distinction. The mailbox may not require the reporter to use a form. It must accept logs, headers and examples. Validation is intended to confirm that the recipient understands the process, monitors the mailbox, takes measures and responds. The official implementation notice also makes clear that keeping those contacts current became an operating obligation. LACNIC’s implementation notice

The help page’s cure design has merit. A holder with another validated contact can substitute it. A holder can resend validation. A stale address can be changed. These are repair paths, not a demand that the organization prove the truth of a particular abuse allegation before regaining access.

That defence should be kept intact. The issue is not whether LACNIC may verify a notice channel. It is whether “the mailbox has not been validated” and “the organization may not enter its registry portal” are joined by a public control record precise enough to audit.

“Access” is too large a noun

MiLACNIC is not simply the screen where a contact clicks a confirmation box. It is an administrative interface for managing an organization’s relationship with the registry. The public help page uses the broad word “access,” yet it does not say which functions remain available while the gate is active.

Can the member see its records but not edit them? Can it repair a reverse-DNS delegation? Can it alter a ROA during a routing incident? Can it inspect a pending transfer, maintain an IRR object, answer a contractual notice, pay an invoice or open a security ticket? Does the block apply to an individual user, an organization or every resource associated with it? Does an NIR present the same gate? The sources examined here do not answer those questions.

These are not demands for confidential system design. They are descriptions of consequence. A registry can publish them without exposing credentials, internal authorization logic or attack paths. The earlier proposal itself demonstrated the distinction by stating broad scope and two classes of exception in ordinary policy language.

The difference matters because registry controls do not all carry the same clock. A missed routine validation may be curable over days. A route-origin correction during an incident may be urgent. A payment screen may be contractually necessary. A contact-edit path must remain available for the gate to be curable at all. If the public word “access” covers each function identically, that is an important policy fact. If it does not, the exceptions are equally important.

Without a function-level statement, the member cannot know whether the gate is a narrow interlock around contact maintenance or a broad dependency on one mailbox state. The public cannot tell whether implementation still resembles the earlier draft, reflects a later decision or varies by interface.

The right artifact is a control-consequence manifest

The repair need not be a new constitution or an elaborate appeals tribunal. LACNIC can publish a compact, versioned manifest for the gate.

It should begin with authority: the policy section, contract provision or delegated procedure that permits the control. It should identify the activation event, including the initial and additional validation clocks and the evidence that notice was delivered through other available contacts. It should state the subject of the block—user, organization, resource set or function—and list the exact MiLACNIC actions that are disabled.

The same record should list the actions preserved. Contact replacement and validation are already visible. Contractual and payment functions appeared as exceptions in an earlier draft; the current record should say whether they remain exceptions rather than invite an inference. Incident-sensitive functions such as RPKI, reverse DNS or other resource maintenance should be named according to the real implementation, not assumed in either direction.

The manifest should also identify the cure event and restoration sequence. “Until validation” does not say whether access returns instantly, after a queue runs, after staff review or after synchronization with an NIR. A maximum review or restoration objective would let an operator plan without converting the registry into an insurer of every downstream effect.

Finally, it should carry a version, effective date, responsible role, correction route and supersession history. The phrase “at this stage” on a page dated 2021 is not a change log. A member should be able to tell whether the gate is temporary, permanent, amended or replaced.

This is thin governance in the useful sense. It does not ask LACNIC to decide whether every abuse report is true. It asks the institution to account for a control it operates over its own portal.

What the evidence does not show

No affected organization has been identified in the sources. There is no public count of lockouts, no measured duration, no false-positive rate and no evidence of a route, RPKI object, reverse-DNS delegation, transfer or customer service being harmed. The member-only portal was not tested with a member account.

The help page’s broad wording does not prove that every function is disabled. The absence of the lockout clause from the manual does not prove that no other agreement authorizes it. The historical draft’s NIR and payment exceptions do not prove that those details survived implementation. And a CMS publication timestamp does not prove the page’s words have never changed.

Those boundaries make the finding stronger, not weaker. The article does not need an injured member to establish that the public rule and the public control description are separate. It needs only the documents LACNIC itself publishes.

Sources