The intent at the time was to make sure to exclude TLD operators for the ICANN Make Money Fast scheme that was (at the time) getting ready to launch and create potentially thousands of new gTLDs. We were explicit about earlier gTLDs and ccTLDs because at the time (and to the best of my knowledge, still) those were the only two other classes of TLDs.
ICANN Sanctioned applies to the “root server operators” as opposed to the various competing DNS Roots out there that are _NOT_ ICANN sanctioned, as we also didn’t want to open this reservation up to them for (obvious?) reasons. The language is an attempt to clarify those exclusions by including the legitimate intended users of the policy. gTLD operators are singled out because they are not permitted access to this reserved special address pool, but they are allowed a /23 from other customary sources (free pool, transfers, etc.). They are special cased for a reason and I think that the only confusion I see here is an attempt to include them in eligibility to this pool. I oppose the policy as written because I think it would create confusion and potentially open the pool up to gTLD operators which is not the policy intent and was hotly contested during the policy development with very strong support from the community for that exclusion. Owen > On Sep 27, 2025, at 12:28, Martin Hannigan <[email protected]> wrote: > > > > In contrasting the original and this, we skewed closer back to intent. > Original proposal author(s) may have inadvertently created confusion with a > narrowing to ccTLD which we didn't intend. This was hopefully obvious in the > followup discussion regarding service providers and data that was provided, > but clearly not in the policy proposal. > > - TLD Coverage > > Policy statement 4.4.2 just says “TLD operators.”, but earlier in 4.4 main > text “ICANN-sanctioned gTLD operators” is singled out with /23 limits. This > creates a confusing mismatch. Are gTLDs special-cased while ccTLDs fall under > “TLD operators”? Or are all TLDs covered? Ambiguous. > > - 4.4. Clarity > > "CII includes Internet exchange points (IXPs), core DNS service providers > (e.g. ICANN-sanctioned root and ccTLD operators) ARIN, and IANA". > > I don't know what a core DNS service provider is, but as long as it's clear > we're using e.g. properly the "ccTLD" part isn't necessarily completely > wrong, but is confusing. I don't recall that ccTLD's are ICANN "sanctioned". > Perhaps it would've been best to remove that fluff? We did in the original > proposal since it was confusing. > > This isn't terrible, but somewhere down the line the lack of clarity (or too > much clarity) is going to be problematic for names infrastructure. If > anything, naming infrastructure scales far more efficiently than other CII > which I don't see any problems to solve for past practices. > > HTH, YMMV > > -M< > > > > On Tue, Sep 23, 2025 at 12:32 PM ARIN <[email protected] <mailto:[email protected]>> > wrote: >> On 18 September 2025, the ARIN Advisory Council (AC) advanced the following >> Draft Policy to Recommended Draft Policy status: >> >> * ARIN-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation >> >> The text of the Recommended Draft Policy is below, and may also be found at: >> >> https://www.arin.net/participate/policy/drafts/2024_5/ >> >> You are encouraged to discuss all Recommended Draft Policies on PPML prior >> to their presentation at the next ARIN Public Policy Consultation (PPC). >> PPML and PPC discussions are invaluable to the AC when determining community >> consensus. >> >> The PDP can be found at: >> >> https://www.arin.net/participate/policy/pdp/ >> >> Draft Policies and Proposals under discussion can be found at: >> >> https://www.arin.net/participate/policy/drafts/ >> >> Regards, >> >> Eddie Diego >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> Recommended Draft Policy ARIN-2024-5: Rewrite of NRPM Section 4.4 >> Micro-Allocation >> >> AC Assessment of Conformance with the Principles of Internet Number Resource >> Policy: >> >> "Following a review of community feedback, staff and legal recommendations, >> and AC discussions, Draft Policy ARIN-2024-5: Rewrite of NRPM Section 4.4 >> Micro-Allocation, was found to conform to the principles of the ARIN Policy >> Development Process. Based on being fair, impartial, and technically sound, >> this Draft Policy was moved to Recommended Draft state by the Advisory >> Council. If adopted by the ARIN Board Of Trustees, it would update the >> NRPM’s terminology from “Micro-Allocation” to “Critical Internet >> Infrastructure” in order to better describe the usage for the resources >> described in Section 4.4, as well as clarify qualification and usage >> requirements for resources allocated under the section." >> >> Problem Statement: >> >> The current NRPM Section 4.4 language hasn’t aged well. As the ARIN 53 >> policy experience report demonstrated, 4.4 has also become difficult to >> implement by ARIN staff. The growth and use of Internet Exchanges have also >> changed. The overhaul seeks to improve technical soundness, respect the >> privilege of a dedicated pool and to more closely observe conservation >> principles using clear, minimum and enforceable requirements and >> underscoring the value of routability of allocated prefixes as required. >> >> Policy Statement: >> >> 4.4 Critical Internet Infrastructure (CII) Allocations >> >> ARIN will reserve a /15 equivalent of IPv4 address space for critical >> Internet infrastructure (CII) within the ARIN RIR service area. Allocations >> from this pool will be no smaller than a /24. Sparse allocation will be used >> whenever practical. CII includes Internet exchange points (IXPs), core DNS >> service providers (e.g. ICANN-sanctioned root and ccTLD operators) ARIN, and >> IANA. >> >> ICANN-sanctioned gTLD operators may justify up to the equivalent of an IPv4 >> /23 block for each authorized gTLD, allocated from the free pool or received >> via transfer, but not from the above reservation. This limit of a /23 >> equivalent per gTLD does not apply to gTLD allocations made under previous >> policy. >> >> Previous allocations under this policy must continue to meet the >> justification requirements of this policy. >> >> Use of this policy for CII is voluntary; address holders that qualify for >> CII allocations may use allocations obtained via other means for CII >> resources. ARIN will publish a record of all addresses allocated under this >> section for research purposes. >> >> 4.4.1 Internet Exchange Allocations >> >> Internet exchange operators must justify their need by providing a minimum >> of three initial participants not under common control connected to a >> shared, physical switching fabric to be used for the purpose of the exchange >> of data destined for and between the respective networks. This justification >> must include participant names, ASNs and contact information for each named >> participant. The applicant’s Internet exchange-affiliated ASNs are not >> eligible to be included in meeting the participant requirement. >> >> Allocated addresses may be publicly reachable at the operator’s discretion >> but must be assigned only to resources directly related to the operation of >> the IXP. >> >> 4.4.2 TLD Allocations >> >> TLD operators will provide justification of their need and certification of >> their status as currently active zone operators. >> >> 4.4.3 Additional Requests >> >> A recipient may request up to a 24-month supply of IPv4 resources under this >> section. Requests for additional resources under this section will be >> evaluated using Section 4.2.4.1’s usage requirements. >> >> In cases where fulfilling the request by expanding the existing allocation >> is not possible, a single prefix sized to accommodate both the prior and >> additional requested allocation will be issued to facilitate renumbering. >> The original allocation must be returned to ARIN within 12 months of the new >> allocation. >> >> Timetable for Implementation: Immediate. >> >> >> >> >> >> _______________________________________________ >> ARIN-PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ([email protected] >> <mailto:[email protected]>). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected] <mailto:[email protected]> if you experience any >> issues. > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues.
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
