> On May 23, 2024, at 18:54, Martin Hannigan <[email protected]> wrote: > > > > On Thu, May 23, 2024 at 21:31 Owen DeLong via ARIN-PPML <[email protected] > <mailto:[email protected]>> wrote: >> I support the spirit of the draft policy, but I’d like to see a change that >> I don’t think will be controversial… >> >> 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).” >> >> 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. >> >> Owen > > >> > > Thanks Owen. > > I’m one of four authors. And many interested. Speaking for myself. > > The reason its specific is to address specific issues. > > 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.
I don’t think a Virtual IX would pass muster with my proposed language. I think I’ve proposed language that solves this problem. > 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. Again, I believe the language I proposed does, in fact, address this issue as well, without restricting it specifically to an Ethernet based fabric. Requiring a fabric with physical infrastructure was the intent of my proposed language, just that it doesn’t have to be ethernet. > Neither are corner cases. > > 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. > > 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. Well, I think requiring a switch (as opposed to some possible other mechanism of physical interconnection) is also unnecessarily specific, but I think as long as a physical interconnection infrastructure is required (which I believe is accomplished in my proposed language), I think we’re good. If you see holes in my proposed language, I’m certainly open to wordsmithing them. Owen > > >> >> >> > On May 21, 2024, at 09:26, ARIN <[email protected] <mailto:[email protected]>> >> > wrote: >> > >> > 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. >> > >> > Draft Policy ARIN-2024-5 is below and can be found at: >> > >> > https://www.arin.net/participate/policy/drafts/2024_5 >> > >> > 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: >> > >> > * Enabling Fair and Impartial Number Resource Administration >> > * Technically Sound >> > * Supported by the Community >> > >> > 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) >> > >> > >> > Draft Policy ARIN-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation >> > >> > 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. 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. >> > >> > ARIN 4.4 CI Assignments >> > >> > 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. >> > >> > 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. >> > >> > 4.4.1 Internet Exchange Assignments >> > >> > • Internet Exchange operators must justify their need by providing the >> > following: >> > >> > • 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 >> > >> > • Justification must include: >> > - Three unique participant names and ASNs not under common control >> > - Direct contact information for each participant >> > >> > • Staff can reasonably validate hardware existence and participants intent >> > >> > • Applicant Internet Exchange affiliated ASNs are not eligible to be >> > included in meeting the participant requirement >> > >> > • Assigned addresses may be publicly reachable at the operators discretion >> > and be used to operate all of the Internet Exchange's infrastructure >> > >> > 4.4.2 Root and ccTLD Assignments >> > >> > Root and ccTLD operators will provide justification of their need and >> > certification of their status as currently active zone operators. >> > >> > >> > >> > _______________________________________________ >> > 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] >> <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.
