Summary

  • The 31 October 2025 SPARK revision proposed one request for an ASN under NRPM §5.1, an IPv4 /24 from the §4.10 transition block and IPv6 sized under the existing end-user or ISP rules. Ordinary justification and utilization requirements would still apply.
  • ARIN's Advisory Council minutes record a unanimous rejection as outside policy scope. Council discussion suggested that ARIN might handle the bundle internally and that its author should use the suggestion channel.
  • The original September version specified a /40 IPv6 minimum and fee amounts; the October revision removed those prescriptions. The visible fight at the end was over who should define the application path.

The first SPARK proposal arrived on 17 September 2025 with the confidence of a starter kit sold in a single box. A new operator would request an ASN, an IPv4 /24 from the IPv6 transition reserve and an IPv6 allocation together. The text even proposed a /40 minimum, a $500 entry fee and $250 a year. Its author argued that fragmented requests and confusing prices push small networks toward intermediaries. Those market claims belong to the proponent; the proposal supplied no measurement of how many operators took that route.

By 31 October, the revised proposal had become much narrower. An applicant had to hold no ARIN number resources. The ASN would still meet §5.1, the IPv4 /24 would still come from §4.10, and IPv6 size would follow §6.5.8 for an end user or §6.5.1 for an ISP. Normal justification and utilization requirements in §§4, 5 and 6 remained. The fixed /40 and the fee schedule were gone. SPARK now asked mainly for one front door to three existing decisions.

That revision matters because a bundle can mean two quite different things. It can change who qualifies and how much the registry issues. Or it can keep the eligibility tests intact while changing how a newcomer submits information and sees the result. The October text leaned hard toward the second. It still proposed a new NRPM section, however, putting the front door into the policy book.

The 31 October Council minutes show where the book shut. BJ described the author's intent as acquiring the different resource needs at the same time. After speaking with the CXO, BJ said ARIN might be able to handle that internally; the author could file a suggestion to test community support for the functionality. The CXO and president called the proposal out of scope. The Council then rejected it unanimously, without comments on the motion, and the president asked that the rejection letter recommend a suggestion.

The vote was a jurisdictional decision. It did not settle whether a small network would benefit from a single request. It settled that this Council would not make that request path a number-resource policy. The practical design question moved to ARIN's service machinery, where a suggestion can be considered without turning every screen and queue into an NRPM clause. That may be the sensible home for interface design. It also changes the public receipt: operators can track a proposed policy by its text and Council disposition, while a service change needs its own published requirements, release record and observable behavior.

ARIN's proposal index marks SPARK rejected due to scope. Its Consultation and Suggestion Process page describes the route for service and practice suggestions. The active-suggestion list inspected for this article did not show an identifiable SPARK item. The specific missing evidence is a suggestion number or an ARIN implementation notice linking a one-request resource workflow to the rejected proposal. Either would establish the next step; a policy vote alone cannot.

The receipt a newcomer needs

Suppose ARIN builds the one-request path. A prospective operator still has three separate eligibility decisions. A useful receipt would show the ASN criterion applied, the §4.10 IPv4 decision, the IPv6 rule used to size the allocation, and any fee presentation in one traceable case. One form is not one entitlement. A rejected IPv4 request should not leave the operator guessing whether the ASN or IPv6 decision survived. A single confirmation screen that hides three outcomes would recreate the confusion with better typography.

That is the stake behind the procedural comedy. A proposer tried to make entry simpler by writing the front desk into policy. The Council sent the front desk to the suggestion box. Whoever owns that box now controls whether the bundle becomes a working path and how an applicant can prove what happened. SPARK's final outcome is a clean test of an old registry habit: when the policy book declines a service problem, the service owner must leave a record that operators can actually use.

Original SPARK proposal · 31 October revision · Council minutes · ARIN suggestions