Summary

  • LACNIC’s current English, Spanish and Portuguese Bulk WHOIS pages tell an organisation to sign the form, send it to hostmaster, and—if approved—post it to Montevideo. Each page then says forms sent by email are not accepted.
  • The authoritative Spanish policy and the linked English form are clearer about the paper side: the application or original is sent by post, fax is excluded, and LACNIC may publish the request and its decision. They do not explain an email pre-screen stage.
  • This record does not show a failed application or how staff actually work. The last note may be stale, or “not accepted” may mean that an email copy cannot become the controlling original.
  • A small, privacy-safe receipt should name each stage: electronic copy received, review opened, paper original matched, application accepted, decision made, conditions attached, credentials issued, renewed or revoked.

A form can arrive without being accepted

The most important word on LACNIC’s Bulk WHOIS page is not “email” or “post.” It is “accepted.” That verb should identify a transition. Instead, the page uses it at the point where the preceding steps have made the transition difficult to locate.

The English instructions begin with a restricted purpose. Bulk access is for technical research or Internet operations, and LACNIC may approve or deny a request. An applicant must complete the form and have the organisation’s legal representative sign it. Step two says to send the signed form to hostmaster at LACNIC. Step three says that, if the request is approved, the applicant must send the original copy by post to the Montevideo office. A note immediately below says that forms sent by fax or email will not be accepted.

The Spanish and Portuguese pages reproduce the same sequence in their own language. This matters because the ambiguity is not a stray conflict between one official language and a translation. Each reader is told to use an electronic channel and is then told that the same class of submission is not accepted through that channel.

There is a plausible reconciliation. The email attachment may be a convenience copy used for eligibility screening. Approval may be provisional. The paper original may be the artifact that completes the application or forms the agreement. “Not accepted by email” may mean “not finally accepted as the controlling signed instrument,” rather than “do not email us.” That model would make operational sense. LACNIC’s contact page, after all, expressly routes requests for Bulk WHOIS or Bulk RDAP to hostmaster.

But the public instructions do not name that model. They use “request,” “form,” “approved,” “original” and “accepted” without assigning a state to each. An applicant cannot tell from the page whether staff begin substantive review on receipt of the email, whether approval precedes contract formation, whether the paper original must match the emailed file exactly, or whether an email sent in obedience to step two is merely correspondence with no application status.

The policy keeps the paper threshold, not the electronic one

LACNIC tells readers that the Spanish PDF of its Policy Manual is authoritative and that the web rendering is a convenience. Version 2.21 places Bulk WHOIS in section 8. It limits access to technical research and Internet operations, allows the request and the approving or denying resolution to be published, and tells the applicant to complete the form and send it to the street address at Rambla República de México 6125 in Montevideo. Fax is expressly excluded. The text does not describe the three-step email-first path now displayed on the access page.

The English application form says the original copy is to be sent by post. It asks for the organisation, its address, a contact person, a reason and intended use, and the legal representative’s signature, position and date. It sets acceptable-use limits, prohibits redistribution without prior written consent, provides for access to be discontinued in case of misuse, and places disputes under Uruguayan law with conciliation and arbitration provisions. This is not merely a helpdesk ticket. The signed artifact carries conditions that matter after download.

The registration-documents page reinforces that character by describing the Bulk WHOIS agreement as the document to be signed by organisations that want complete access to the data. The service also has institutional history: LACNIC’s 2003 launch announcement says it was discussed and approved at LACNIC IV and ratified by the Board, then points readers to the application document for details.

None of those sources proves that LACNIC has mishandled a real case. None tells us that paper is unnecessary, that an email has legal effect, or that a mailed original is ignored. They establish a narrower point: the public service has a durable policy and a signed-use instrument, while its current front-door instructions leave the relationship between the electronic and paper artifacts unnamed.

Controlled data makes the missing state consequential

Bulk WHOIS is not an ordinary newsletter download. It collects registry information at a scale that can support security research, operational analysis and traffic work. The same scale can amplify privacy and misuse risks. LACNIC therefore restricts purpose, prohibits direct marketing and similar uses, limits redistribution, and reserves sanctions. The application asks who is responsible and why the data is needed.

That control model depends on a reliable join between identity, declared purpose, signed terms, decision and access credential. If the electronic copy is only a screening device, it should not silently become the authoritative agreement. If the paper original controls, staff and applicant need a way to show which electronic copy it matches. If approval arrives before the original, the approval needs a state such as conditional or pending original. If credentials are issued only after the paper instrument is accepted, the public instructions should say so.

The remedy is not to publish applications or expose research plans by default. The policy says that a request and resolution may be published; it does not require publication. A receipt can protect private details while proving process. It can carry a case identifier, the applicable policy and form versions, a hash of the emailed copy, the time and purpose of receipt, a field stating whether review has begun, a hash match for the paper original, signatory-verification state, a decision and conditions, and the lifecycle of the issued credential.

For the public, aggregated numbers would be enough to test much of the service: applications received, incomplete cases, approvals, denials, median decision time, credentials active, renewals and revocations. Small counts can be suppressed where they risk identification. The individual applicant would receive the detailed receipt; the community would receive a privacy-safe operating account.

Correction should preserve the path applicants already followed

A wording repair has to respect the possibility that people have already followed the current steps. Deleting the email instruction without a transition note could make earlier submissions look improper. Deleting the final warning could imply that a scan is a sufficient original. The safer correction would date the change and label both channels.

For example: send a signed electronic copy to hostmaster for preliminary review; receipt does or does not start the review clock; approval at that stage is conditional; if conditionally approved, send the original by post; the application becomes accepted only after the original is matched and acknowledged. If that is not the real process, the page should describe the real one with the same precision.

The distinction is small enough to fit in one paragraph, yet important enough to govern a controlled-data service. A good intake page does not merely list actions. It tells the applicant which action changes the case.

Sources