<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Right, I think I missed the justifications for these oppositions
and only read that someone else somewhere else were opposed as a
reason of why it should be opposed.</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 20/12/2023 05:37, Owen DeLong wrote:<br>
</div>
<blockquote type="cite"
cite="mid:ABD6FBC9-000F-4B58-8DAD-202DC67BD504@delong.com">
<pre class="moz-quote-pre" wrap="">I don’t know if anyone has asked.
I do know that at the ARIN meeting in San Diego they were relatively vocally opposed.
I know they have also opposed this on virtually every policy mailing list in every RIR where this has been proposed.
Modulo a few IPv4 fan boys who are bad at math, IMHO, it has very little support and much opposition. However, I’m no longer on the AC, so my opinion here is worth the cost of the postage for this email.
Owen
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Dec 19, 2023, at 10:45, Fernando Frediani <a class="moz-txt-link-rfc2396E" href="mailto:fhfrediani@gmail.com"><fhfrediani@gmail.com></a> wrote:
Hello there Matthew
That's actually a very good point and question. In general I would say Exchange point operators, even commercial ones who still play an important role on Internet ecosystem development. In the other hand public Internet Exchange Points with more transparent policy of who can apply should be best regarded above the previous one.
I guess the main point to look at who predictable would be this reserve if both type of entities would request, what is the cost for the RIR to to supervise its usage and all the stuff involved.
If there are concerns about how much this type of assignments can be made of course I would say to restrict to public Internet Exchange Points with more open and transparent policies or with no commercial interest.
Fernando
On 18/12/2023 17:03, Matthew Wilder wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Fernando,
Indeed I think there is a great deal of public support for IXPs to be able to continue to be an important part of the landscape. We as shepherds of ARIN-2023-2 are considering all of the feedback we are seeing on PPML.
I just wish to clarify, by IXP do you mean a public Internet Exchange Point which is more or less transparent about its list of peers and how new peers can apply to connect regardless of other direct business relationships? Or do you mean the "Exchange point operators" - a term which is not defined in NRPM - which can currently qualify for a /24 prefix with only 3 peering participants (which may or may not be in business together) and without necessarily any degree of transparency?
Thanks,
Matthew Wilder
On Mon, Dec 18, 2023 at 11:29 AM Fernando Frediani <a class="moz-txt-link-rfc2396E" href="mailto:fhfrediani@gmail.com"><fhfrediani@gmail.com></a> wrote:
I think it is forcing too much for so little. Just give the IPv4 IXPs
need to operate and make people`s life easier. IXPs are a very
important
part of Internet ecosystem that changes a lot of things for better in
terms of redundancy, robustness and performance. Yes IPv4 NLRI
over IPv6
may work but people don't seem to be willing to use it very much
and for
such usage for small chunks it makes it worth.
Just make in a way that is possible and easy for the RIR to know
if one
if misusing it for other proposes and be able to action.
I also don't like the idea of shrinking IPv4 delegations form RIRs
below
/24, but if that is the feasible option than better than nothing.
Fernando
On 25/11/2023 22:33, owen--- via ARIN-PPML wrote:
> The problem I have with this line of thinking is that in
reality, IXPs
> are the place with the least need for an IPv4 prefix.
>
> It’s dirt simple to pass along IPv4 NLRI over an IPv6 peering
session
> these days, even if you’re not doing IPv6 anywhere else in your
network.
>
> The only real consequence of this is to make IPv4 trace routes
look a
> little funky on the hop that traverses the exchange.
>
> Yes, there’s a perceptual hurdle to this and there are those
that view
> an IPv6 only IXP as undesirable compared to a dual-stack one,
but at
> some point, we’re going to just have to get over that.
>
> I don’t support shrinking IPv4 delegations from RIRs below /24 and
> multiple IXPs have argued against doing so.
>
> The only possible gain to this policy is prolonging the
perceived life
> of IPv4 which, IMHO, is a step away from good. (Note, it won’t
prolong
> the actual life of IPv4, just increase the amount of pain involved
> while it lasts).
>
> Owen
>
>
>> On Nov 25, 2023, at 16:55, Martin Hannigan <a class="moz-txt-link-rfc2396E" href="mailto:hannigan@gmail.com"><hannigan@gmail.com></a>
wrote:
>>
>>
>> Went back to work on language that may have an impact. We seem to
>> have dropped three paragraphs from drafts that are in the current
>> policy. I can't tell if it's intentional but I'll assume it was.
>> Doesn't appear clearly marked for deletion unless I missed it. The
>> original or the June edit was also not a mirror of the RIPE
proposal.
>> ARIN can decide if anything needs to be fixed documentation
wise or
>> if we could use the help of a red line for the below. Didn't
matter
>> much anyhow.
>>
>> The easiest way to extend the life of the micro allocation pool
will
>> be to apply better justification standards. Right now, 26% of
US IXPs
>> don't meet the minimum criteria for an initial /24 using the
existing
>> policy. Most of that happened in the last few years and as Aaron
>> Wendell discussed at the last meeting.
>>
>> Here's what I support
>>
>> - Initial allocation of a /26 to a new IXP, and
>> - Include "CI" to keep it simple and consistent. No reason to
single
>> out IXPs
>> - A voluntary global routability requirement determined by
applicant
>> for CI
>> - Tightened utilization requirements for CI
>> - Removing the possibility of other RIR's asking ARIN for
allocations
>> (glitch?)
>>
>> If the root or a TLD can't do it, what makes anyone think an
IXP can?
>>
>> I agree with my RIPE friends' comments regarding up front
costs. It
>> already costs $11,000 for a "free" IXP without a /24. Add a
transfer
>> /24 and it's $22,000 not including opex, RIR fees,
depreciation, etc.
>> If it does cost a future IXP an additional $11,000 for a /24
and it's
>> not easily absorbed (lots of that happening today) they failed and
>> will not start up. Turning the knobs on network economics
should go
>> slow - as they also acknowledged. And should als be applied to
non-CI
>> first. That seems like a faster way to enable better transition.
>>
>> On a last note. It would be nice to have a "style sheet" so we had
>> consistency with defined terms and language. Repeating "under this
>> section" and other "time honored traditions" makes policy hard to
>> read when it doesn't have to be.
>>
>> 4.4 Micro-allocation
>>
>> ARIN will make IPv4 micro-allocations to critical infrastructure
>> (“CI”) providers of the Internet, which includes Internet Exchange
>> Points (“IXP”), IANA authorized root servers, top-level domain
>> operators and this RIR. Requests for IPv4 allocations will be no
>> smaller than a /26 or larger than a /23 for allocations which
require
>> global reachability. Global reachability requirements will be
>> determined by the requestor. ARIN will maintain a previously
reserved
>> /15 of IPv4 address space for the purposes of CI allocations.
>>
>> 4.4.1 Additional Requirement for IXPs
>>
>> An IXP requesting an initial IPv4 allocation from the blocks
>> specifically reserved for this purpose will initially be
assigned a
>> /26 allocated from a /24 by default if they demonstrate three
>> independent ASN’s are planning to interconnect on the IXP fabric
>> using the requested allocation. An IXP requesting an allocation
>> larger than a /24 must show their plan to utilize more than 50% of
>> the requested allocation size up to a /23. Allocations larger
than a
>> /23 will be considered on a case-by-case basis using usual and
>> customary allocation practices in effect at the time of the
request.
>>
>>
>>
>>
>> On Tue, Nov 21, 2023 at 12:34 PM ARIN <a class="moz-txt-link-rfc2396E" href="mailto:info@arin.net"><info@arin.net></a> wrote:
>>
>> In accordance with the Policy Development Process (PDP), the
>> Advisory Council met on 16 November 2023.
>>
>> The AC has advanced the following to Draft Policy status
(will be
>> posted separately for discussion):
>>
>> * ARIN-prop-327: Reduce 4.18 maximum allocation
>>
>> The AC advances Proposals to Draft Policy status once they are
>> found to be within the scope of the Policy Development Process
>> (PDP) and contain a clear problem statement.
>>
>> The AC has advanced the following to Recommended Draft Policy
>> status (will be posted separately for discussion):
>>
>> * ARIN-2023-1: Retire 4.2.1.4. Slow Start
>>
>> The AC advances Draft Policies to Recommended Draft Policy
status
>> once they have been fully developed and meet ARIN's
Principles of
>> Internet Number Resource Policy. Specifically, these
principles are:
>>
>> * Enabling Fair and Impartial Number Resource Administration
>>
>> * Technically Sound
>>
>> * Supported by the Community
>>
>> The AC is continuing to work on:
>>
>> Draft Policies:
>>
>> * ARIN-2022-12: Direct Assignment Language Update
>>
>> * ARIN-2023-2: /26 initial IPv4 allocation for IXPs
>>
>> * ARIN-2023-4: Modernization of Registration Requirements
>>
>> * ARIN-2023-6: ARIN Waitlist Qualification
>>
>> * ARIN-2023-7: Clarification of NRPM Sections 4.5 and 6.11
>> Multiple Discrete Networks and the addition of new Section 2.18
>> Organizational Identifier (Org ID)
>>
>> Recommended Draft Policies:
>>
>> * ARIN-2023-5: Clean-up of NRPM Sections 4.3.4, 4.4, 4.10
and 6.10.1
>>
>> The PDP can be found at:
>>
>> <a class="moz-txt-link-freetext" href="https://www.arin.net/participate/policy/pdp/">https://www.arin.net/participate/policy/pdp/</a>
>>
>> Draft Policies and Proposals under discussion can be found at:
>>
>> <a class="moz-txt-link-freetext" href="https://www.arin.net/participate/policy/drafts/">https://www.arin.net/participate/policy/drafts/</a>
>>
>> Regards,
>>
>> Eddie Diego
>>
>> Policy Analyst
>>
>> American Registry for Internet Numbers (ARIN)
>>
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
>> Unsubscribe or manage your mailing list subscription at:
>> <a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
>> Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
>>
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
>> Unsubscribe or manage your mailing list subscription at:
>> <a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
>> Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
>
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
> Unsubscribe or manage your mailing list subscription at:
> <a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
> Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
</body>
</html>