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

[Martin Hannigan]

On Sun, Feb 23, 2025 at 10:45 AM Fernando Frediani <fhfrediani at gmail.com>
wrote:

>  Hello
>
> With regards to the possible usage expansion of these micro allocations to
> sTLDs as suggested I am strongly against it. The amount of these operators
> has grown significantly after ICANN opened the doors for so many that could
> be a misuse of resources if this privilege was given to them. Also it
> doesn't seem to me they should be considered "core DNS service providers"
> and after all these are normally business focused on specific and localized
> interests rather than broad and/or community interests so they should have
> means to get the space they need to run these services.
>

Fernando, s/TLD's are different from g/TLD. The former is closed and
controlled. The latter is open. s/TLD can also operate open like g/TLD and
has as time progresses. The g/TLD has more root.zone entries than the s/TLD
by far. They're also limited by being required to be "in the ARIN region"
per the update which reduces s/TLD to almost nothing beneficiary wise. I
can think of a bunch of nitpicks, but based on the data shared seems not
worth it.

The s/TLD did expand although I believe slightly when ICANN opened up the
TLD's not the cc) to commercial operations. g/TLD have already been able to
use the policy. However, the URL's to the data I linked shows (I believe)
that DNS hosting companies are using the policy. This was a better outcome
than "fear of the unknown" which partly drove the original policy. I'm not
sure it matters to differentiate cc/s/g for this policy proposal (or the
last one) but I would argue there isn't a need to make changes to something
that works IMHO. Hope that helps to clear up. If we wanted to be clear and
concise, TLD would say the same thing.

I see nothing wrong with the IXP uses. The intent language is a shiny
object. No argument here to take it out.

Warm regards,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20250224/01624625/attachment.htm>