<div><br></div><div dir="auto"><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 23, 2024 at 21:31 Owen DeLong via ARIN-PPML <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">I support the spirit of the draft policy, but I’d like to see a change that I don’t think will be controversial…<br>
<br>
1. ARIN should not be specifying network technologies. “A physically present ethernet switch” is way too specific for NRPM IMHO. I would propose, instead, that we specify “connected to a shared peering fabric via physical infrastructure (e.g. a shared ethernet switch).”<br>
<br>
In the past, we have had internet exchanges that were (e.g.) ATM based and had multiple physical switches spread over a variety of locations. I don’t know that there are currently any non-ethernet based exchanges still in operation, but I also don’t know what kind of networking technology might occur next week. For example, I think it would be perfectly valid to set up an infiniband exchange if there were enough interested participants, but under this proposed policy, that would not be allowed.<br>
<br>
Owen</blockquote><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
</blockquote><div dir="auto"><br></div><div dir="auto">Thanks Owen. </div><div dir="auto"><br></div><div dir="auto">I’m one of four authors.  And many interested. Speaking for myself.</div><div dir="auto"><br></div><div dir="auto"><div><div dir="auto" style="font-family:-apple-system,helveticaneue;font-size:19px;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;background-color:rgba(0,0,0,0);border-color:rgb(0,0,0);color:rgb(0,0,0)">The reason its specific is to address specific issues. </div><div dir="auto" style="font-family:-apple-system,helveticaneue;font-size:19px;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;background-color:rgba(0,0,0,0);border-color:rgb(0,0,0);color:rgb(0,0,0)"><br></div><div dir="auto" style="font-family:-apple-system,helveticaneue;font-size:19px;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;background-color:rgba(0,0,0,0);border-color:rgb(0,0,0);color:rgb(0,0,0)">Virtual IX’s may be able to justify 4.4 resources and applying the hardware test tries to prevent that. Many may claim Virtual IX are educational in nature. This is good. However, they are not CI as a result and not in need of precious 4.4 resources.</div><div dir="auto" style="font-family:-apple-system,helveticaneue;font-size:19px;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;background-color:rgba(0,0,0,0);border-color:rgb(0,0,0);color:rgb(0,0,0)"><br></div><div dir="auto" style="font-family:-apple-system,helveticaneue;font-size:19px;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;background-color:rgba(0,0,0,0);border-color:rgb(0,0,0);color:rgb(0,0,0)">The other is IX preparing and certifying peers, getting resources but then never deploying a switch fabric. Wanted to have a good revocation trigger. Likely to be used rarely if ever, but for thoroughness. </div><div dir="auto" style="font-family:-apple-system,helveticaneue;font-size:19px;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;background-color:rgba(0,0,0,0);border-color:rgb(0,0,0);color:rgb(0,0,0)"><br></div><div dir="auto" style="font-family:-apple-system,helveticaneue;font-size:19px;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;background-color:rgba(0,0,0,0);border-color:rgb(0,0,0);color:rgb(0,0,0)">Neither are corner cases. </div><br></div>On the switch tech l2 piece ATM etc does contradict demonstrated standards. And if IX tech changes, policy could be changed. If someone tells ARIN they’re deploying an ATM switch as an IX in 2024 it should set off alarm bells IMHO.</div><div dir="auto"><br></div><div dir="auto">As long as the physical switch component is kept I don't think there would be heartache. But hope the reasons help everyone understand the inside baseball.</div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br>
<br>
> On May 21, 2024, at 09:26, ARIN <<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>> wrote:<br>
> <br>
> On 16 May 2024, the ARIN Advisory Council (AC) accepted “ARIN-prop-333: Rewrite of NRPM Section 4.4 Micro-Allocation” as a Draft Policy.<br>
> <br>
> Draft Policy ARIN-2024-5 is below and can be found at:<br>
> <br>
> <a href="https://www.arin.net/participate/policy/drafts/2024_5" rel="noreferrer" target="_blank">https://www.arin.net/participate/policy/drafts/2024_5</a><br>
> <br>
> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are:<br>
> <br>
> * Enabling Fair and Impartial Number Resource Administration<br>
> * Technically Sound<br>
> * Supported by the Community<br>
> <br>
> The PDP can be found at:<br>
> <br>
> <a href="https://www.arin.net/participate/policy/pdp/" rel="noreferrer" target="_blank">https://www.arin.net/participate/policy/pdp/</a><br>
> <br>
> Draft Policies and Proposals under discussion can be found at: <a href="https://www.arin.net/participate/policy/drafts/" rel="noreferrer" target="_blank">https://www.arin.net/participate/policy/drafts/</a><br>
> <br>
> Regards,<br>
> <br>
> Eddie Diego<br>
> Policy Analyst<br>
> American Registry for Internet Numbers (ARIN)<br>
> <br>
> <br>
> Draft Policy ARIN-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation<br>
> <br>
> Problem Statement:  <br>
> <br>
> 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. Growth and use of Internet Exchanges has 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 assigned prefixes as required.<br>
> <br>
> ARIN 4.4 CI Assignments<br>
> <br>
> The intent of this policy is not to unreasonably preclude the use of an allocated or assigned prefix in servicing the needs of critical infrastructure of the Internet.<br>
> <br>
> 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, ccTLD operators, 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.2 transfers are allowed. Use of this policy for CI is voluntary. ARIN will publish all 4.4 allocated addresses for research purposes.<br>
> <br>
> 4.4.1 Internet Exchange Assignments<br>
> <br>
> • Internet Exchange operators must justify their need by providing the following:<br>
> <br>
> • A minimum of three initial participants connected to a physically present ethernet switch fabric to be used for the purpose of Internet Exchange facilitated peering<br>
> <br>
> • Justification must include:<br>
>       - Three unique participant names and ASNs not under common control<br>
>       - Direct contact information for each participant<br>
> <br>
> • Staff can reasonably validate hardware existence and participants intent<br>
> <br>
> • Applicant Internet Exchange affiliated ASNs are not eligible to be included in meeting the participant requirement<br>
> <br>
> • Assigned addresses may be publicly reachable at the operators discretion and be used to operate all of the Internet Exchange's infrastructure<br>
> <br>
> 4.4.2 Root and ccTLD Assignments<br>
> <br>
> Root and ccTLD operators will provide justification of their need and certification of their status as currently active zone operators.<br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> ARIN-PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
<br>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div></div>