Summary

  • draft-ietf-regext-balance-03 proposes a read-only EPP view of one or more financial accounts; it is an active Internet-Draft, not an RFC or evidence of deployment.
  • Balance Available, Cash Balance, Credit Line, Execution Limit and Notification Threshold answer different questions and must not be collapsed into one reassuring number.
  • A successful balance query neither reserves funds nor authorizes the next billable command. Only the later command response can record that decision.

At 10:00:00 a registrar asks a registry for its balance. The response says USD 800 is available. At 10:00:01 the registrar submits a domain create. A dashboard built around one large green number may describe that sequence as straightforward: funds existed, so the command should pass. The proposed EPP Balance Mapping shows why that conclusion is too fast.

The draft’s model contains five financial values, not one. Balance Available is the sum of Credit Line and Cash Balance. The Credit Line is calculated from active credit instruments chosen by server policy; it may include ordinary or emergency credit and can shrink when an instrument expires. Cash Balance moves with payments, withdrawals and billable debits or credits, including fees and taxes. The figures belong to a particular Balance account, whose name and main currency are part of its identity.

Then comes the value that actually describes the admission boundary: Execution Limit. It can be based on Balance Available or Cash Balance. Its default is zero, but the server may set it above zero to preserve a margin for server-initiated costs such as auto-renewals. A registrar can therefore see a positive amount and still be correctly blocked before exhausting it. The limit may also be negative, allowing some billable work after the selected measure crosses zero. The sign of the headline balance alone does not tell the operator which side of the gate it occupies.

The Notification Threshold is a different boundary again. When the selected measure reaches or falls below that threshold, the server inserts one low-balance poll message for the affected Balance. The threshold and Execution Limit must use the same basis, but they need not have the same value. An alert can arrive while commands remain possible. A block can occur according to a safety margin that is not the dashboard’s visual zero. A poll receipt proves that the server queued an alert; it does not prove a refusal, an invoice, insolvency or settlement.

Revision 03 makes the accounting identity harder to lose by adding multiple Balance accounts. One registrar may have separate accounts for TLDs or commercial arrangements, perhaps two in USD and another in EUR. A low-balance message can identify one or more named accounts. Automation that strips the account name, currency or basedOn attribute risks applying a true figure to the wrong operational context. Summing USD and EUR balances into a home-grown global total would erase the very policy boundaries the server exposes.

Multi-currency detail adds another useful but bounded observation. Optional cashBalanceByCurrency elements show the original currency, amount and direct-quotation conversion rate used to produce Cash Balance in the account’s main currency. That explains the reported aggregate. It is not a promise that the same rate will price the next command, settle an invoice or remain available after the query. The draft defines disclosure, not an executable foreign-exchange quote.

The protocol boundary is unusually clear. The mapping defines <info> and low-balance <poll> responses. It defines no balance create, update, renew, delete or transfer operation. RFC 5730 classifies <info> as a read-only query and requires each later EPP command to receive its own response. Revision 03 defines no hold, reservation token, quote lifetime or compare-and-swap condition joining the observation to a future transform. Between the two messages, other debits, refunds, deposits, withdrawals, credit changes or server-initiated charges may alter the state.

This does not make the balance response weak. It makes it precise. The response is evidence that the authenticated server represented specified values for the logged-in client at that protocol moment. It lets software explain the arithmetic and warn before a limit is crossed. It does not carry the authority of a later command decision into the past.

The standards status deserves the same discipline. Revision 03 was posted on 24 September 2026 as a REGEXT Working Group Internet-Draft with Standards Track intent. Its namespace, schema and requested IANA entries describe proposed interoperability machinery. They do not establish IETF approval, implementation by a named registry, use by a registrar, operational correctness or a financial outcome.

Sources