Summary

  • APNIC’s public roadmap targets the third quarter of 2026 for an improvement that would continuously track IRT email validity and check it when a member logs in, instead of relying on a static account lock flag.
  • The proposal is about the source and timing of an access decision. It does not, on the public evidence, replace the existing six-month validation cycle, the 15-day Invalid marker or the 30-day MyAPNIC limitation.
  • An email address, a completed validation challenge, an IRT object, an account and a login decision are different stateful objects. Treating them as one Boolean creates the very drift the roadmap is trying to remove.
  • A privacy-safe IRT access decision receipt could identify the state versions, policy clocks, aggregation rule and decision source used at login without exposing an email address or validation code.

The decision should meet the evidence at the door

Imagine two views of the same APNIC member account. In the first, the account carries a lock flag copied from an earlier IRT validation result. In the second, the underlying contact has since been validated. If the login service consults only the copied answer, the account may remain limited after the reason for the limitation has disappeared. Reverse the sequence and the same design can preserve an unlocked answer after the relevant validity state has changed.

APNIC has not said that either event happened to a particular member. Its public roadmap instead names the failure mode as an outcome to prevent: accounts remaining incorrectly locked or unlocked. The proposed solution is precise. APNIC would continuously track all IRT email addresses and check their validity at login rather than rely on a static account lock flag. The item sits with the Membership team, affects APNIC Login and Whois, and carries a Q3 2026 target.

This is not merely a fresher user-interface badge. It changes which fact is authoritative at the moment access is decided. A stored lock flag is a derived consequence. Current IRT email validity is the state from which that consequence ought to be derived. Moving the read to login time can shorten the distance between them.

“Current” still needs a definition. The roadmap does not publish the final data model, the rollout date inside Q3, the rule for accounts associated with several IRT objects, or the rule for an IRT object containing several email attributes. Nor does it present the change as operational today. Those omissions are not faults in a roadmap. They are the implementation questions on which the control will turn.

Three clocks already govern the state

The proposed login check enters a system with an existing policy history. APNIC records prop-125 as implemented. Its current resource policy requires an IRT object for every resource record. The email and abuse-mailbox contacts in that object must be monitored, and complaints sent to them must receive a prompt response.

The contact-validation mechanism has three important clocks:

  1. APNIC validates IRT contacts periodically or every six months.
  2. An account holder has 15 days after receiving the validation email to complete the check. If validation fails, the IRT object is marked Invalid in Whois.
  3. If validation still fails after 30 days, MyAPNIC access is limited until the contacts are validated.

APNIC’s 2019 implementation announcement says the regime began on 30 June 2019. The public validation form asks the recipient to enter a unique code sent by email. That event demonstrates access to the mailbox for the challenge. It supplies the evidence from which a validity state can advance.

Nothing in the roadmap says the login-time design abolishes these clocks. The six-month cadence determines when fresh proof is due. The 15-day point affects the Whois object’s visible state. The 30-day point affects portal access. Login is the decision moment that should read the result. The policy produces the state; the login service consumes it.

Collapsing those moments would create a new ambiguity. A member could not tell whether access was limited because a six-month due date passed, a challenge expired, a 15-day rule marked an object Invalid, a 30-day consequence became effective, or a login service read an older answer. A more current check is most valuable when it also preserves the reason.

One Boolean cannot carry five kinds of state

The IRT system contains at least five distinguishable objects.

First is the email-address record: an address appearing in an IRT object, with a privacy-sensitive value and a history. Second is the validation challenge: an issuance time, delivery attempt, expiry and successful or unsuccessful code entry. Third is the IRT object itself, which has an identity, version and attributes. APNIC’s IRT object guide distinguishes e-mail from abuse-mailbox and uses mnt-by to name the maintainer that authorizes changes.

Fourth is the member account and its scope: the set of resources, IRT objects and contacts relevant to access. Fifth is the login decision: an evaluation at a timestamp under a particular rule version, returning allow or limit with a reason.

The transitions are related but not interchangeable. A code can be accepted for one address without changing a second address. An IRT object can be edited, changing which address matters. An account can be connected to more than one resource record and therefore more than one IRT object. A login decision can be correct for the state it read yet become obsolete after a later validation or edit.

Continuous tracking helps only if the joins are explicit. The login service must know which IRT objects belong in the account’s decision scope, which email attributes within them are relevant, how each current state was derived, and what rule combines the results. Otherwise the system replaces one opaque flag with an opaque live query.

The aggregation rule is the hard policy surface

Suppose an IRT object contains two abuse mailboxes and one general email address. Must all three be current? Is one validated abuse mailbox sufficient? If a single email is reused across multiple IRT objects, does one completed challenge advance every occurrence, or only the record that issued the challenge? If an account holds resources whose IRT objects disagree, does the strictest state govern the entire account, only an affected function, or only the resource concerned?

The public roadmap does not answer those questions, so this article does not invent an answer. It does show why the answers must be versioned. “Checked validity at login” is reproducible only when an operator can state the set checked and the combining rule applied.

A sensible design would separate raw evidence from derived decisions. A validation event can say that a challenge for an address identifier was completed at a time. A state record can say that the address was valid from one effective time until a due date or superseding event. An IRT evaluation can list the address states it considered. An account decision can cite the IRT evaluations and the rule version. Each layer may then be corrected without pretending the earlier evidence never existed.

This matters during recovery. If a contact validates at 10:04 and the member attempts login at 10:05, support should be able to see whether the login read the new state. If it did not, the remedy is a propagation or snapshot problem. If it did, but an additional IRT address remained overdue, the remedy concerns scope or policy. Those are different incidents, owned by different teams.

Mailbox control is not complaint performance

Prop-125 connects periodic email verification to an operational goal: keeping the people responsible for network abuse contactable. APNIC policy also requires the listed contacts to be monitored and abuse complaints to receive a prompt response. Yet the evidence for those propositions is different.

Entering a code shows that someone with access to a message completed a challenge. It does not show that every later complaint reached the right queue, survived filtering, received human attention or led to a remedy. Conversely, a delayed validation challenge does not prove that a mailbox is nonexistent or that a specific complaint was ignored. Delivery, mailbox control, monitoring, triage and resolution are separate observations.

The distinction protects both complainants and members. Complainants should not be told that a green validation state proves good abuse handling. Members should not face an abuse finding merely because a policy validation clock expired. MyAPNIC limitation is an account-control consequence tied to contact validation; it is not a court judgment, a resource revocation or an adjudication of the network’s conduct.

Login-time evaluation should therefore consume contact-validity evidence without inflating it. Complaint-response performance may deserve its own measurements and process, but it should not be smuggled into the meaning of an email challenge.

A receipt for the decision, not another flag

APNIC could make the proposed control auditable with an IRT access decision receipt. This is an editorial recommendation, not a reported APNIC commitment. The receipt need not reveal the contact address or validation code. It should reveal enough structure to reproduce the access decision.

For each login evaluation, record:

  • a timestamp and privacy-safe account reference;
  • the IRT object keys and object versions included in scope;
  • a masked or hashed identifier for each email address considered;
  • the most recent successful validation event, current state and effective time for each identifier;
  • the six-month due date, 15-day deadline and 30-day consequence date that apply;
  • the versions of the scope, aggregation and policy rules;
  • the exact state snapshot read by APNIC Login;
  • the allow or limit outcome, typed reason code and decision source; and
  • links to any correction, manual review or superseding decision.

“Decision source” is important during migration. It can distinguish a result produced from live IRT state from one inherited from a legacy static flag. APNIC can then measure how much traffic still depends on the older path, compare conflicting results before cutover, and retire the flag only when the live evaluation is demonstrably complete.

The receipt should also be asymmetric. The member may see object identifiers, masked contacts and deadlines. Support may see additional internal event references. A public proof, if ever needed, could expose only a receipt digest and a typed status. Auditability does not require publishing a mailbox.

Sources