[arin-ppml] ARIN-2024-5 Rewrite of NRPM Section 4.4 Micro-Allocation - Community Questions

[Tyler O'Meara]

Hi Martin,

I largely support your proposals, but have a few minor language nits:

> CI includes Internet Exchanges, IANA authorized root servers, TLD operators or
> their service providers, ARIN, and IANA.

We should clarify that only the actual authoritative DNS servers qualify as CII;
as such I propose we use the following language:
CII includes Internet Exchanges, IANA authorized authoritative Root DNS servers,
TLD authoritative DNS servers, and critical services operated by ARIN and IANA.

Presumably we don't consider whatever vendor Verisign uses for their corporate
email to be CII, for example.

> Addresses assigned from this pool may be revoked if no longer in use or not
> used for approved purposes.

Replace approved purposes with either CII or purposes approved under this
subsection (4.4). We should make it clear that the "approved purposes" is
restricted to just 4.4, not the NRPM as a whole.

> ICANN authorized root zone and TLD operators will provide a justification for
> their need.

I think we should replace will with must. 

Additionally, I will note that the current text granted a default approval of 1
/23 per gTLD (albeit from the general pool, rather than the 4.4 pool). I'm
indifferent about whether we keep that, but wanted to make sure everyone was
aware of that change since it hasn't been discussed yet (as far as I can
recall).

On Wed, 2025-02-26 at 16:50 -0500, Martin Hannigan wrote:
> 
> 
> 
> I would propose rewording a few things to make some progress.
> ARIN 4.4 CI Assignments
> 
> ARIN will reserve a /15 equivalent of IPv4 address space for Critical
> Infrastructure (CI) of the Internet within the ARIN RIR service area.
> Assignments from this pool will be no smaller than a /24. Sparse allocation
> will be used whenever practical. CI includes Internet Exchanges, IANA
> authorized root servers, TLD operators or their service providers, ARIN, and
> IANA. Addresses assigned from this pool may be revoked if no longer in use or
> not used for approved purposes. Only Section 8.? transfers are allowed. Use of
> this policy for CI is voluntary. ARIN will publish all 4.4 allocated addresses
> for research purposes.
> 
> Bill, I have no idea which transfer section would be best. I can see pitfalls
> for CI in all of them. Perhaps any? Or at least M&A.
> 
> Here's a proposal to reword the language around root and ccTLD utilization:
> Look at the data and you can see most of the TLD's are hosted. The hosters are
> using the address. They are not, as far as.can tell, using them to host
> websites or anything other than zones, but I didn't feel the need to check.
> This gives the pool scale and I support leaving it alone. sTLD was never
> intended to be excluded, just assumed part of the gTLD and which the USA ones
> almost all have their own resources (.gov). Based on the data, it appears ARIN
> knows what is doing here too so rather than break anything, being more clear
> as to who benefits is worthwhile.
> For extra double clarity, remove all references to ccTLD, make it TLD, and:
> ICANN authorized root zone and TLD operators will provide a justification for
> their need.
> 
> The layer 2 language change seems fine as I recall it below and reworded:
> Doesn't really matter and nothing to argue about.
> - A minimum of three initial participants connected to a physically present
> layer 2 switch to be used for the purpose of Internet Exchange 
> facilitated peering
> 
> Slight rewording to be even more clear:
> - Assigned addresses may be publicly reachable at the operators discretion.
> 
> This shouldn't be needed at all but since the ARIN staff want us to tell them
> it's ok there it is.
> 
> IXP Utilization (which has nothing to do with "routing")
> What exactly is the question staff utilization analysis wise? Not in the
> experience report and not in the policy review. In fact, there is no policy
> review yet.
> 
> Hope that helps.
> 
> -M<
> 
> 
> 
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.