Summary

  • AFRINIC's public New Membership Registration Portal responded normally, but its three named pre-application guides all pointed to one /become-member base route that returned HTTP 404 on 31 August 2026.
  • The three labels do different work: explaining the application process, establishing eligibility for membership and listing supporting documents. One shared failure therefore removes three promised forms of context at once.
  • The portal and AFRINIC's current membership page still publish substantial requirements, checklists and a support route. The evidence does not show a failed form or a harmed applicant.
  • A versioned preflight-document manifest could bind each label to a tested target, governing rule, content hash, safe alternative, owner and correction history.

The New Membership Registration Portal does not hide its advice in a footer. Before the login and sign-up controls, it tells organisations that every request must pass through the Membership Application Process. It recommends reading three documents before submission so an applicant can verify eligibility, understand the policies that apply and assemble the required material.

Then it names them:

  1. Membership Application Process;
  2. Eligibility for Membership;
  3. Supporting Documents.

These are not three decorative labels for the same idea. The first should tell an applicant what happens and in what order. The second should explain whether the organisation and its request fall within the registry's rules. The third should say what evidence will make the request reviewable. Process, rule and proof are separate dependencies in any consequential application.

Yet the three links are separated only by fragments. They point to https://afrinic.net/become-member#steps, #eligibility and #documents. In a fresh no-store capture on 31 August 2026, the shared non-www base route returned HTTP 404. The www form of the same base route returned 404 too. Both responses had the same 146-byte body.

That is the complete observation. It is precise, and it is smaller than an outage.

The NMRP page itself returned HTTP 200 on both public hosts checked. No account was created. No login was attempted. No form was submitted. There is no evidence here of a rejected application, a lost document, a delayed allocation, a wrong eligibility decision or a failed registry service. Treating a dead guidance dependency as proof that the application system is down would be as careless as treating an online login screen as proof that every application can be completed correctly.

The portal makes a strong case for itself

The best defence of AFRINIC's present design is visible on the same page.

The current AFRINIC membership page supplies another path. It advises readers to verify eligibility, review the policy manuals and prepare documentation before submission. It presents eligibility and document cards, resource criteria and checklists, then links back to the application portal.

An applicant who encounters the 404 is therefore not left with a blank institutional surface. There are useful requirements, a human contact and a current membership hub. Nor is a single canonical guide inherently a bad design. One maintained page can be better than three copies that drift apart. Fragment links can take each reader directly to the relevant part while preserving one source of editorial truth.

But that defence depends on the canonical page existing, the fragments remaining stable and the portal knowing which version of the guidance it invokes. When all three labels share one base URL, one routing error removes all three deep links together. Redundancy in labels is not redundancy in dependencies.

A label is a promise about meaning

The 404 matters because the three links sit before submission. They are not optional background reading offered after a decision. The portal itself recommends them so applicants can test readiness before exposing time, documents and expectations to a formal workflow.

Suppose an organisation can infer the required uploads from the portal but cannot see the intended process guide. It may know what to collect without knowing when staff can edit an application, when the applicant can amend it or how a request changes state. Suppose the eligibility summary remains visible but the detailed link does not. A checklist can show common criteria without establishing which policy version controls an unusual case. Suppose the document list on the portal is enough for one IPv4 request but not for a different resource or organisational form.

A label promising “Supporting Documents” implies a maintained scope, not merely a few examples.

None of those scenarios is proved to have happened. They show why the three semantic duties should not be collapsed in the audit record simply because their links share a page.

The distinction also protects AFRINIC. If a prospective member relies on a summary and later discovers a more specific requirement, the registry should be able to show which guide was current, where it was linked, which policy it explained and when the dependency was tested. Without that chain, a routine clarification can look arbitrary even when the underlying decision is correct.

NMRP already has a language of versions

AFRINIC's public software changelog provides an important contrast. Its NMRP tab records releases from 2019 through version 2.9.0 in June 2021. The entries are not limited to invisible maintenance. They include textual updates, consent fields, policy implementations, application-state handling, document uploads, applicant editing and the push of approved data into MyAFRINIC.

That history proves two modest things. First, NMRP has been treated as versioned software. Second, the boundary between instructions and behaviour has changed over time. An instruction was removed in one release; information pages and disclaimers were updated in another; a registration could be returned to draft; applicant editing could continue until Member Services locked the record.

The changelog does not prove that version 2.9.0 is the current deployment. It does not identify the content version intended by the three links. It does not say when /become-member last worked or whether a repair is already under way. Its value is architectural: AFRINIC already knows how to describe change as a sequence of named releases. The preflight guidance deserves the same discipline.

Software versioning without guidance versioning leaves a quiet gap. The form may change what it asks, the policy may change what qualifies and the guide may change what an applicant prepares. If those clocks are not joined, the applicant sees only the current screen while the reviewer may be applying a different explanatory baseline.

Publish the dependency, not an incident narrative

The useful public object is not a dramatic outage report. It is a small, versioned application-preflight documentation manifest.

Manifest field What it would establish
Portal version and landing-page hash Which application surface presented the links
Link label and semantic duty Whether the dependency explains process, eligibility or evidence
Fragment and canonical target The exact location intended for the reader
Content version or hash The guide text that was in force
Controlling policy or agreement version The authority the guide interprets
Validation time and HTTP result Whether the public dependency was tested
Last success and first failure, when known A bounded timeline without invented duration
Safe alternate and support route How an applicant continues when guidance is unavailable
Fail, warn or continue behaviour What the portal does when a required dependency fails
Owner, correction time and supersession Who maintains the link and how an earlier state is replaced

The manifest need not expose applicants, uploaded files, staff notes, support tickets, internal topology or credentials. A public copy could be no more sensitive than a release note. What matters is that a label, a rule and a document version can be joined without asking the applicant to reconstruct them from browser history.

The design should also classify dependency severity. If the detailed guide is explanatory and the portal contains the controlling requirements, the portal can warn and offer a safe alternate. If the unavailable document carries a requirement not reproduced elsewhere, the application surface should not quietly proceed as though the preflight had succeeded. It should state which guidance is unavailable and provide an authorised path to continue.

That distinction prevents two opposite errors. The first is overreaction: declaring the entire membership system unavailable because three links share a 404. The second is indifference: treating pre-application guidance as disposable because the form still loads. A registry can keep the service open while acknowledging that a decision dependency needs repair.

The three links should fail independently in the record

AFRINIC can fix the immediate route with a redirect or a restored page. That would solve the reader's current problem. It would not, by itself, answer which content version the portal intended or whether the three semantic sections remained complete after the repair.

A stronger closure would test each label as its own contract even if all three continue to live on one page. The process link should land on a process section. The eligibility link should land on the controlling eligibility explanation. The documents link should land on a scoped list that makes clear when further evidence may be requested. Automated validation should verify the status, fragment and expected semantic marker, not merely that the server returned 200.

That last point matters. A home-page redirect can turn a 404 into green monitoring while still failing the applicant. HTTP health is necessary but not sufficient. The link has succeeded only when it arrives at the intended explanation.

AFRINIC's portal already asks applicants to arrive prepared. The reciprocal obligation is simple: the preparation path should identify and test its own dependencies. Three labels can share one page. They should not share one silent failure.

Sources