<div dir="ltr"><div dir="ltr"> Hello
<br>
<br>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.
<br>
<br>Regarding the Internet Exchange allocations I normally don't see a big 
problem with routing part of the space that is used for other things 
other than the LAN (for example for User Portal, Looking Glass hosting, 
etc), but here comes a dilemma.
<br>Imagine the RIR have to assign an exclusive /24 for a new smaller IXP and 
they will have usage for only 4 or 5 IP addresses for hosting its basic 
stuff. That would be a major waste. And another /24 for the LAN which is 
fine. So an IXP would always consume a /23 while 50% is known to be 
probably wasted, unless properly justified.
<br>Having alternatives and considering the growth of IXPS, for this hosting 
part whatever scarce resources are available should be privileged for 
the LANs. Therefore it becomes harder to agree 100% on that, though I 
see the point and justifications and would like to see other's opinions 
on this point.
<br>
<br>Fernando <br></div><br><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p><br><br>
    </p>
    <div>On 22/02/2025 19:31, Martin Hannigan
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div dir="ltr"><br>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Tue, Feb 18, 2025 at
            3:08 PM Chris Woodfield <<a href="mailto:cwoodfield@gmail.com" target="_blank">cwoodfield@gmail.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div>As AC shepherds for the critical infrastructure draft
              (2024-5) we'd like to get input on the draft policy text
              and collect some feedback on open issues that the
              shepherds have received from multiple sources. This will
              help us edit the draft for presentation at ARIN 55 and, if
              there is consensus, advancement to the NRPM.<br>
              <br>
              The current draft text can be found on ARIN’s policy page
              here:<br>
              <a href="https://www.arin.net/participate/policy/drafts/2024_5/" target="_blank">https://www.arin.net/participate/policy/drafts/2024_5/</a><br>
              <br>
              Below are the points in the current proposed policy text
              that we’d like to get community feedback on. <br>
            </div>
          </blockquote>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div><br>
              ----<br>
              Under 4.4, Critical Internet Infrastructure (CII)
              Allocations:</div>
          </blockquote>
          <div><br>
          </div>
          <div>[ clip ]</div>
          <div><br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div><br>
              “[Critical Internet Infrastructure] includes Internet
              Exchanges, IANA-authorized root servers, ccTLD operators,
              ARIN and IANA”<br>
              <br>
              - The current text references “core DNS service
              providers”, while the proposal text is more restrictive,
              only specifying ccTLD operators as eligible to apply for
              CII resources. Should this be expanded to encompass other
              types of TLD operators, such as gTLD, sponsored TLD,
              and/or possibly others? Or simply revert to the more
              expansive language in existing text?</div>
          </blockquote>
          <div><br>
          </div>
          <div>These leading questions seem well suited to rewriting the
            14th amendment, but I digress:</div>
          <div><br>
          </div>
          <div>
            <p class="MsoNormal" style="margin:0in;font-family:Aptos,sans-serif"><font size="2"><span>The difference between sponsored TLDs
                  (sTLDs)
                  and generic TLDs (gTLDs) is that sTLDs can operate in
                  a restricted (closed)
                  manner if their sponsor chooses, whereas gTLDs are
                  generally open for public
                  registration. However, both can be for-profit
                  entities.<span></span></span></font><span><font size="2"> </font></span></p>
            <p class="MsoNormal" style="margin:0in;font-family:Aptos,sans-serif"><span><font size="2"><br>
                </font></span></p>
            <p class="MsoNormal" style="margin:0in;font-family:Aptos,sans-serif"><span><font size="2">A significant number of sTLDs now function
                  similarly to gTLDs, as many of their originally
                  intended special-purpose models
                  failed. When Section 4.4 was originally drafted, gTLDs
                  and ccTLDs were included
                  due to uncertainty about their impact. </font></span>For
              example, why should pornhub, an sTLD, be granted
              privileged resources when Erol's Internet, a network
              operator, has to sit on the waiting list or use the
              transfer market? <span><font size="2">Today, it is clear
                  that neither gTLDs
                  nor sTLDs require special support or protection within
                  ARIN policy. ccTLD, the root and IXPs were the
                  intended clarity.</font><span></span></span></p>
          </div>
          <div><br>
          </div>
          <div>Here's who has benefitted from CI:</div>
          <div><br>
          </div>
        </div>
        <div class="gmail_quote">V4: <a href="https://pastebin.com/Sec5dPrz" target="_blank">https://pastebin.com/Sec5dPrz</a></div>
        <div class="gmail_quote">V6: <a href="https://pastebin.com/dthW7TsN" target="_blank">https://pastebin.com/dthW7TsN</a></div>
        <div><br>
        </div>
        <div>Not too bad!</div>
        <div class="gmail_quote"><br>
        </div>
        Regarding ccTLDs, two key considerations. "in-region"
        eligibility and naturally embedded government systems for most.
        Perhaps including language to ensure the resources aren't used
        for hosting, would be appropriate? Based on the current 4.4
        allocations I would venture to guess most of the ccTLD is
        hosted. In that case, clarifying that the allocations are for
        the ccTLD's themselves, not their hosters would also be
        appropriate.
        <div class="gmail_quote"><br>
        </div>
        <div>+1 for routing these prefixes. All or none as well. It was
          never the intent of the policy.</div>
        <div><br>
        </div>
        <div>Warm regards,</div>
        <div><br>
        </div>
        <div>-M<</div>
        <div class="gmail_quote"><br>
        </div>
        <div class="gmail_quote"><br>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.
</pre>
    </blockquote>
  </div>

</blockquote></div></div>