Re: [arin-ppml] Draft Policy ARIN-2024-8: Restrict the Largest Initial IPv6 Allocation to /20

[David Farmer via ARIN-PPML]

 given in a single allocation. If an organization is
>> using its
>> IPv6 space efficiently (as defined later in Section 6), they're more than
>> welcome to get more allocations. I will note that the standard to obtain
>> these
>> subsequent blocks is considerably higher than to get the first block. It
>> is
>> easily conceivable that an organization that would qualify for a /16 under
>> today's NRPM could not even meet the utilization requirements for a /20
>> in order
>> to get a second /20, let alone a /16.
>>
>> When it comes to smallish blocks, the desire to enable aggregation and
>> smaller
>> routing tables outweighs concerns about address conservation. However, I
>> believe
>> that once we're talking about blocks larger than a /20, conservation
>> concerns
>> outweigh routing table concerns.
>>
>> Second, it's been mentioned that it is not believed that many
>> organizations
>> could qualify for a /16 block. It is very difficult to come up with a good
>> metric to determine the size of an organization, but I think an
>> organization's
>> v4 allocations are probably a reasonable proxy for this use case.
>>
>> The organization that received the /16 block has v4 allocations totaling
>> 50
>> /24s[1]. Under the current ARIN fee schedule, this would make them a
>> "Small"
>> organization. According to the presentation made by Nancy Carter at ARIN
>> 53[2],
>> there are currently (as of April 2024) 1,864 Small ARIN organizations,
>> and a
>> further 1,559 ARIN organization larger than Small. Given the context of
>> the
>> numbers, I believe this is only counting RSA members and *not* LRSA
>> members, so
>> the actual number of ARIN orgs of this size is likely substantially
>> higher.
>>
>> Given that the number of organizations which could reasonably request a
>> /16 is
>> on the same order of magnitude as the number of IANA-allocatable /16s, I
>> personally belive the current policy is too liberal in giving out
>> massively
>> sized IPv6 allocations.
>>
>> Tyler
>>
>>
>> [1] https://bgp.tools/rir-owner/ARIN-CAPITA-120
>> [2]
>>
>> https://www.arin.net/participate/meetings/ARIN53/materials/monday/arin53_treasurer.pdf
>>
>> On Thu, 2024-06-27 at 18:17 -0500, David Farmer via ARIN-PPML wrote:
>> >
>> >
>> > On Thu, Jun 27, 2024 at 5:04 PM William Herrin  wrote:
>> > > On Thu, Jun 27, 2024 at 2:46 PM David Farmer  wrote:
>> > > >   As I said, the current policy seems to be functioning as intended.
>> > >
>> > > Hi David,
>> > >
>> > > I can't prove a negative, so let me turn the question around on you:
>> > > we know a /16 has been allocated. We can't know how they justified it
>> > > because that information is private. Can you produce a -notional-
>> > > justification for a /16 that we all agree is -reasonable-? If you
>> > > cannot, then what purpose is served by allowing such consumptive
>> > > registrations?
>> > >
>> >
>> >
>> > The current policy has been in effect since ARIN-2011-3 was implemented
>> in
>> > January 2012. One /16 allocated in over a decade doesn't represent a
>> problem.
>> > Instead, it indicates a successful policy that balances the need for
>> > justification with the ability to provide substantial allocations. The
>> data
>> > provided in the proposal doesn't demonstrate a problem. If we see a
>> rash of
>> > /16 allocations, I might change my mind, but until then, I don't
>> support a
>> > change at this time.
>> >
>> > 1 16
>> > 8 20
>> > 22 22
>> > 39 24
>> >
>> > Thanks.
>> >
>> > --
>> > ===
>> > David Farmer   Email:far...@umn.edu
>> > Networking & Telecommunication Services
>> > Office of Information Technology
>> > University of Minnesota
>> > 2218 University Ave SEPhone: 612-626-0815
>> > Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> > ===
>> > ___
>> > ARIN-PPML
>> > You are receiving this message because you are subscribed to
>> > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> > Unsubscribe or manage your mailing list subscription at:
>> > https://lists.arin.net/mailman/li

Re: [arin-ppml] Draft Policy ARIN-2024-8: Restrict the Largest Initial IPv6 Allocation to /20

[David Farmer via ARIN-PPML]

On Fri, Jun 28, 2024 at 11:26 AM Tyler O'Meara  wrote:

> Hi David,
>
> If I may, why do you believe nibble alignment is important?


Nibble alignment is important because it significantly reduces operational
complexity. Reverse DNS delegations for IPv6 are made on nibble boundaries.
Also, humans are less likely to screw up when allocations are made on
nibble boundaries.

Furthermore, from a conservation perspective, a few /16 allocations pose
little difference compared to a slightly larger number of /20 allocations.
Also, all the RIR allocations above /24 make little difference from a
conservation perspective compared to the more significant number of
allocations between /32 and /24.

I recognize that /16 allocations offend some people's sensibilities; I can
respect that, and they should support this policy. However, in my opinion,
a policy change is not warranted, especially by a single /16 allocation
being made in a decade.

Thanks.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2024-8: Restrict the Largest Initial IPv6 Allocation to /20

[David Farmer via ARIN-PPML]

On Fri, Jun 28, 2024 at 10:01 AM William Herrin  wrote:

> On Thu, Jun 27, 2024 at 4:17 PM David Farmer  wrote:
> > On Thu, Jun 27, 2024 at 5:04 PM William Herrin  wrote:
> >> we know a /16 has been allocated. We can't know how they justified it
> >> because that information is private. Can you produce a -notional-
> >> justification for a /16 that we all agree is -reasonable-?
> >
> > The current policy has been in effect since ARIN-2011-3 was
> implemented[..]
>
> Yes, yes, only one registrant has thus far had the chutzpah to seek
> and acquire a /16. I have already acknowledged the truth of that
> claim; you need not continue repeating it.
>
> Perhaps you could stop deflecting the question I asked you in return:
> Do you, David Farmer, believe there exists a justification for an
> *initial* allocation of a /16 of IPv6 addresses which would withstand
> public scrutiny? An allocation to an organization which has never
> before held ARIN IPv6 addresses. If you do, would you care to offer us
> such a hypothetical to examine?
>

I considered this question back in 2011 when the question of /16 or /20
came up in the discussion of ARIN-2011-3. I concluded it was possible to
justify a /16. Let me put the question slightly differently: Is it possible
to justify more than a /20? There were already /19s allocated by other
RIRs, so I concluded that it is possible to justify more than a /20. I also
believe nibble alignment is important, so I support /16 as the maximum
allocation. Nevertheless, such /16 allocation should be rare; one in a
decade aligns with that belief.

However, those who think it is impossible to justify a /16 for an initial
allocation should support this policy.

Thanks.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2024-8: Restrict the Largest Initial IPv6 Allocation to /20

[David Farmer via ARIN-PPML]

On Thu, Jun 27, 2024 at 5:04 PM William Herrin  wrote:

> On Thu, Jun 27, 2024 at 2:46 PM David Farmer  wrote:
> >  As I said, the current policy seems to be functioning as intended.
>
> Hi David,
>
> I can't prove a negative, so let me turn the question around on you:
> we know a /16 has been allocated. We can't know how they justified it
> because that information is private. Can you produce a -notional-
> justification for a /16 that we all agree is -reasonable-? If you
> cannot, then what purpose is served by allowing such consumptive
> registrations?
>

The current policy has been in effect since ARIN-2011-3 was implemented in
January 2012. One /16 allocated in over a decade doesn't represent a
problem. Instead, it indicates a successful policy that balances the need
for justification with the ability to provide substantial allocations. The
data provided in the proposal doesn't demonstrate a problem. If we see a
rash of /16 allocations, I might change my mind, but until then, I don't
support a change at this time.

1 16
8 20
22 22
39 24

Thanks.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2024-8: Restrict the Largest Initial IPv6 Allocation to /20

[David Farmer via ARIN-PPML]

On Thu, Jun 27, 2024 at 4:35 PM William Herrin  wrote:

> On Thu, Jun 27, 2024 at 2:31 PM David Farmer  wrote:
> > On Thu, Jun 27, 2024 at 4:23 PM William Herrin  wrote:
> >> John Curran has already said that ARIN would accept a wide range of
> >> esoteric network designs as justifying an initial /16, provided they
> >> were presented in good faith.
> >
> > I would support a policy to clarify that 6RD does not justify
> > a /20 or /16.
>
> Or... and humor me here... we could reduce the cap to something
> sustainable regardless of how folks design their networks and stop
> concerning ourselves with whether they're designing their networks as
> we think they should.
>

Provide me with evidence that the current policy is unsustainable, and I
could change my mind, but one /16 allocation being made by ARIN is not
evidence that the current policy is unsustainable. It is not even a
pattern; it is an anecdote at best. As I said, the current policy seems to
be functioning as intended.

Thanks.
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2024-8: Restrict the Largest Initial IPv6 Allocation to /20

[David Farmer via ARIN-PPML]

On Thu, Jun 27, 2024 at 4:23 PM William Herrin  wrote:

> On Thu, Jun 27, 2024 at 2:19 PM David Farmer  wrote:
> > To qualify for a /16 or /20, you must show your need
> > using section 6.5.2.1—Size, and 6RD wouldn't qualify,
> > at least not in my opinion.
>
> Hi David,
>
> John Curran has already said that ARIN would accept a wide range of
> esoteric network designs as justifying an initial /16, provided they
> were presented in good faith.
>

I would support a policy to clarify that 6RD does not justify a /20 or /16.
I don't see the need for or support any other changes at this time. The
current policy is working as intended.

Thanks

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2024-8: Restrict the Largest Initial IPv6 Allocation to /20

[David Farmer via ARIN-PPML]

On Thu, Jun 27, 2024 at 4:03 PM William Herrin  wrote:

> On Thu, Jun 27, 2024 at 1:42 PM David Farmer  wrote:
> > 6RD is a red herring, ARIN-2010-2 capped justifications for transition
> technology (6RD) at /24, in 6.5.3.1.
> >
> > 6.5.3.1. Subsequent Allocations for Transition
> > Justification for the subsequent subnet size will be based
> > on the plan and technology provided with a /24 being the
> > maximum allowed for a transition technology.
>
> Hi David,
>
> A) 6rd is not necessarily a transitional technology. Certainly the
> NRPM does not define it so. If I say my use is permanent, what basis
> would ARIN staff have to disagree?
>
> B) The concern expressed in the policy proposal was for *initial*
> justifications. Even if ARIN determined that 6rd could account only
> for a /24 of efficient use for a *subsequent* allocation, the
> addresses would already be gone in the initial allocation which places
> no such constraint.
>
> Regards,
> Bill Herrin
>

That is the wording the community wanted at the time. We didn't want to
limit the policy to just 6RD, and at the time, the providers who wanted 6RD
already had allocations.

Nevertheless, I don't believe ARIN would approve a /16 or a /20 for a
justification as trivial as 6RD, so it is still a red herring.

To qualify for a /16 or /20, you must show your need using section
6.5.2.1—Size, and 6RD wouldn't qualify, at least not in my opinion.

Thanks.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2024-8: Restrict the Largest Initial IPv6 Allocation to /20

[David Farmer via ARIN-PPML]

Sorry, that was  ARIN-2010-12.

On Thu, Jun 27, 2024 at 3:41 PM David Farmer  wrote:

> 6RD is a red herring, ARIN-2010-2 capped justifications for transition
> technology (6RD) at /24, in 6.5.3.1.
>
> 6.5.3.1. Subsequent Allocations for Transition
> Subsequent allocations will also be considered for deployments that cannot
> be accommodated by, nor were accounted for, under the initial allocation.
> Justification for the subsequent subnet size will be based on the plan and
> technology provided with a /24 being the maximum allowed for a transition
> technology. Justification for transitional allocations will be reviewed
> every 3 years and reclaimed if they are no longer in use for transitional
> purposes. All such allocations for transitional technology will be made
> from a block designated for this purpose.
>
> Thanks
>
> On Thu, Jun 27, 2024 at 3:00 PM Mark Andrews  wrote:
>
>> Well that looks like an area of policy that needs to be tightened.
>>
>> I dislike IETF’s advice to use 32 bits with /64s and 6rd as there is an
>> incredible amount of wastage.  For /48s its insane wastage.
>>
>> Even with the disjointed GUA IPv4 address assignments ISPs tend to only
>> have addresses in a few /8s.  6rd can be trivially configured to have a
>> prefix per /8 using 24 bits rather than 32 bits and there would be a small
>> multiple if /24s of IPv6 space used rather than a /16.   Yes the border
>> router would have a slightly more complex configuration if you have
>> multiple pops in multiple /8s using it.
>>
>> If you are not using GUAs then you don’t need to use 32 bits as there is
>> no benefit in making it that big as it can’t simplify anything.  10/8 24
>> bits is the biggest you would go. 100.64/10 is 22 bits.  These are maximum
>> sizes.  You need different IPv6 prefixes per instance anyway.
>>
>> --
>> Mark Andrews
>>
>> > On 28 Jun 2024, at 05:19, William Herrin  wrote:
>> >
>> > On Thu, Jun 27, 2024 at 12:14 PM Mark Andrews  wrote:
>> >> I would argue that it is not needed for 6rd as you can pack
>> >> things much denser with proper 6rd parameter management.
>> >
>> > Hi Mark,
>> >
>> > Of course it isn't needed for 6rd. That's not the question. The
>> > question is: does such use technically justify addresses under current
>> > ARIN policy? The answer, as I understand it, is: yes. If I happen to
>> > have a couple dozen disjoint IPv4 allocations and I want to simplify
>> > my 6rd deployment by throwing addresses at it, I have met the
>> > requirements for an ARIN IPv6 allocation that throws 32 bits at 6rd.
>> >
>> > Regards,
>> > Bill Herrin
>> >
>> > --
>> > William Herrin
>> > b...@herrin.us
>> > https://bill.herrin.us/
>>
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>
>
>
> --
> ===
> David Farmer   Email:far...@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2024-8: Restrict the Largest Initial IPv6 Allocation to /20

[David Farmer via ARIN-PPML]

6RD is a red herring, ARIN-2010-2 capped justifications for transition
technology (6RD) at /24, in 6.5.3.1.

6.5.3.1. Subsequent Allocations for Transition
Subsequent allocations will also be considered for deployments that cannot
be accommodated by, nor were accounted for, under the initial allocation.
Justification for the subsequent subnet size will be based on the plan and
technology provided with a /24 being the maximum allowed for a transition
technology. Justification for transitional allocations will be reviewed
every 3 years and reclaimed if they are no longer in use for transitional
purposes. All such allocations for transitional technology will be made
from a block designated for this purpose.

Thanks

On Thu, Jun 27, 2024 at 3:00 PM Mark Andrews  wrote:

> Well that looks like an area of policy that needs to be tightened.
>
> I dislike IETF’s advice to use 32 bits with /64s and 6rd as there is an
> incredible amount of wastage.  For /48s its insane wastage.
>
> Even with the disjointed GUA IPv4 address assignments ISPs tend to only
> have addresses in a few /8s.  6rd can be trivially configured to have a
> prefix per /8 using 24 bits rather than 32 bits and there would be a small
> multiple if /24s of IPv6 space used rather than a /16.   Yes the border
> router would have a slightly more complex configuration if you have
> multiple pops in multiple /8s using it.
>
> If you are not using GUAs then you don’t need to use 32 bits as there is
> no benefit in making it that big as it can’t simplify anything.  10/8 24
> bits is the biggest you would go. 100.64/10 is 22 bits.  These are maximum
> sizes.  You need different IPv6 prefixes per instance anyway.
>
> --
> Mark Andrews
>
> > On 28 Jun 2024, at 05:19, William Herrin  wrote:
> >
> > On Thu, Jun 27, 2024 at 12:14 PM Mark Andrews  wrote:
> >> I would argue that it is not needed for 6rd as you can pack
> >> things much denser with proper 6rd parameter management.
> >
> > Hi Mark,
> >
> > Of course it isn't needed for 6rd. That's not the question. The
> > question is: does such use technically justify addresses under current
> > ARIN policy? The answer, as I understand it, is: yes. If I happen to
> > have a couple dozen disjoint IPv4 allocations and I want to simplify
> > my 6rd deployment by throwing addresses at it, I have met the
> > requirements for an ARIN IPv6 allocation that throws 32 bits at 6rd.
> >
> > Regards,
> > Bill Herrin
> >
> > --
> > William Herrin
> > b...@herrin.us
> > https://bill.herrin.us/
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2024-1: Definition of Organization ID/Org ID

[David Farmer via ARIN-PPML]

The definition below does more than define the term Organization ID/Org ID.
It also defines who is entitled to receive an Org ID and, effectively, who
is entitled to receive resources from ARIN.

Maybe defining who is entitled to receive an Org ID is unnecessary.
However, if necessary, we must discuss who should be entitled to an Org ID
and, therefore, resources from ARIN.

According to John Sweeting's email, "Individuals may as “Sole Proprietors”
receive resources from ARIN for use in the operation of their business
operations."

Others think this is an unnecessary restriction and that individuals should
be able to receive resources without the status of sole proprietor.

To have an informed opinion about this issue, I need to understand better
the business or legal purpose of ARIN's current sole proprietor
requirement.

Thanks

Draft Policy ARIN-2024-1: Definition of Organization ID/Org ID
>
>
>
> Problem Statement:
>
>
>
> During work on a related policy proposal, the NRPM Working Group
> determined that a definition of Organization Identifier (Org ID) should be
> included in the NRPM to add clarity to the term and unify NRPM references
> to match the use of the term in other ARIN publications such as ARIN online.
>
>
>
> Policy Statement:
>
>
>
> Current: None
>
>
>
> Proposed:
>
>
>
> Section 2.18 Organizational Identifier (Org ID)
>
>
>
> An Organizational Identifier (Org ID) is a record that represents a
> business, non-profit corporation, or government entity in the ARIN
> database. An entity must have an Organizational Identifier (Org ID) to
> request Internet Number Resources.
>
>
>
> Comments:
>
>
>
> This definition had previously been included in an earlier policy proposal
> (ARIN-2023-7), but community feedback recommendations on that proposal
> showed a preference for adding the definition separately from that
> proposal. As such the definition is now being proposed as a standalone
> proposal, and the language will be removed from the current ARIN-2023-7
> proposal, allowing the two sections of that proposal to be evaluated
> separately.
>
>
>
> Timetable for Implementation: Immediate
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Advisory Council Meeting Results - November 2023

[David Farmer via ARIN-PPML]

On Mon, Dec 18, 2023 at 2:34 PM Owen DeLong via ARIN-PPML <
arin-ppml@arin.net> wrote:

>
>
> > On Dec 18, 2023, at 11:28, Fernando Frediani 
> 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.
>
> My point is don’t shrink it, let it roll at /24 until it runs out. Once it
> does, IXPs are the least disadvantaged by this fact of virtually any
> network users because (in theory) an IXP language is used only to exchange
> routing information and forward traffic. Since BGP fully supports
> deliverability of IPv4 NLRI over IPv6 peering sessions and IPv4 packets can
> be subsequently delivered without requiring IPv4 on the router interfaces
> on the IXP, despite traditional mindset, there’s no technical or
> engineering reason why an IXP actually needs IPv4 to facilitate IPv4
> traffic exchange.
>
> So instead of shrinking prefixes now and extending the life of the pool
> with no predictable benefit to the community, I favor continuing to
> allocate /24s to IXPs until they run out and then encouraging future IXPs
> to either engage the transfer market or deliver IPv4 NLRI over IPv6.
>

I'll also note that unlike RIPE or any other RIRs, we already have section
4.1.7 Reserved Pool Replenishment. So, as the reserved pools are running
out, any returned resources will go to replenishing them instead of the
waiting list.  Furthermore, we have something like 7 years or so in the
current 4.4 reserved pool, at least based on current allocation rates. So,
we have already implemented another "better" option, at least in my opinion.

Realize it is impossible to extend the runway for IPv4 indefinitely. So, I
think it is time to start singing the popular '50s song, "Que Sera, Sera."

https://en.wikipedia.org/wiki/Que_Sera,_Sera_(Whatever_Will_Be,_Will_Be)


> Owen
>
> >
> > 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  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 

Re: [arin-ppml] Draft Policy ARIN-2023-4: Modernization of Registration Requirements

[David Farmer via ARIN-PPML]

I think the change from 7 days to timely, is unacceptable. Timely is simply
too vague and indefinite, it could mean virtually any timeframe, even up to
90 days or 180 days.

I’d be fine extending the timeframe to 14 days, or 10 business days, to
allow some flexibility for holidays. I’d even accept 21 days, but it needs
to be a definite timeframe.

Thanks

On Tue, Jul 25, 2023 at 11:11 ARIN  wrote:

> On 20 July 2023, the ARIN Advisory Council (AC) accepted “ARIN-prop-322:
> Modernization of Registration Requirements” as a Draft Policy.
>
>
>
> Draft Policy ARIN-2023-4 is below and can be found at:
>
>
>
> https://www.arin.net/participate/policy/drafts/2023_4/
>
>
>
> 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-2023-4: Modernization of Registration Requirements
>
>
>
> Problem Statement:
>
>
>
> Registration is central to the value provided by ARIN to the
>
> community. Registry quality depends greatly upon the timely
>
> registration of reassignments from ISPs to end users. The motivation
>
> for registration has waned since the depletion of the free pool. At
>
> the same time, privacy laws have been introduced in many jurisdictions
>
> across ARIN’s service region which constrain registration in certain
>
> cases. This combination of forces has generally discouraged many ISPs
>
> from registering reassignments. Registration remains vital to a number
>
> of stakeholders, including law enforcement and network operators.
>
>
>
> This proposal aims to modernize the registration-related policies in
>
> Section 4 by introducing language that is meant to make registration
>
> requirements more adaptable to changing privacy laws, while reminding
>
> ISPs of the importance of registration when feasible for the benefit
>
> of the community.
>
>
>
> Policy Statement:
>
>
>
> In section 4.2.3.7.1,
>
> Replace
>
> "Each IPv4 reassignment or reallocation containing a /29 or more
>
> addresses shall be registered via SWIP or a directory services system
>
> which meets the standards set forth in section 3.2."
>
> With
>
> "Each IPv4 reassignment or reallocation containing a /29 or more
>
> addresses shall be registered in the WHOIS directory via SWIP or a
>
> directory services system which meets the standards set forth in
>
> section 3.2, in a timely manner, to the extent permitted and manner
>
> provided by applicable law."
>
>
>
> Retire section 4.2.3.7.2 Reassignments and Reallocations Visible
>
> Within Seven Days
>
>
>
> Rename 6.5.5.1
>
> From
>
> "Reassignment Information"
>
> To
>
> "Reassignment and Reallocation Information"
>
>
>
> In section 6.5.5.1,
>
> Replace
>
> "Each static IPv6 reassignment or reallocation containing a /47 or
>
> more addresses, or subdelegation of any size that will be individually
>
> announced, shall be registered in the WHOIS directory via SWIP or a
>
> distributed service which meets the standards set forth in section
>
> 3.2. Reassignment and reallocation registrations shall include each
>
> client’s organizational information, except where specifically
>
> exempted by this policy."
>
> With
>
> "Each static IPv6 reassignment or reallocation containing a /47 or
>
> more addresses, or subdelegation of any size that will be individually
>
> announced, shall be registered in the WHOIS directory via SWIP or a
>
> distributed service which meets the standards set forth in section
>
> 3.2, in a timely manner, to the extent permitted and manner provided
>
> by applicable law. Reassignment and reallocation registrations shall
>
> include each client’s organizational information, except where
>
> specifically exempted by this policy."
>
>
>
> Retire section 6.5.5.2 Reassignments and Reallocations Visible Within
> Seven Days
>
>
>
> Timetable for Implementation: Immediate
>
>
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of 

Re: [arin-ppml] Re-thinking Section 8.5.6

[David Farmer via ARIN-PPML]

On Fri, Jul 21, 2023 at 6:16 PM Delong.com  wrote:

> On Jul 21, 2023, at 15:39, David Farmer via ARIN-PPML 
> wrote:
>
> So, it sounds like we are talking about a policy aimed purely at ARIN
> members in the 4XL and 5XL fee categories.
>
> Not that I know of, but yes, that was the example cited in the request for
> discussion.
>
> Furthermore, if an organization is large enough, the same statement could
> be made even with an 80% threshold.
> So, let's do the math; if an organization has 5 /8s at 80% full, that is a
> /8 of free space.
>
> As a practical matter,  think there are few (if any) organizations that
> have more than 2 /8s.
>
> Also, a similar statement, relatively speaking, could be made about anyone
> in the XL or higher fee category having more than a /16 of free space.
>
>
> Sure, someone with 5 /24s at 80% utilization has a /24 worth of free space.
>
> These don’t seem like unreasonable ratios as a practical matter, however.
>

Unfortunately, the inquiry said the following:

The crux of the issue is there are very large orgs that could have a /8 or
> more of unused space, yet still qualify for more based on the current
> policy ("must have efficiently utilized at least 50%"). Smaller orgs with
> more immediate needs are in competition for the space, and prices are
> driven up.
>
By focusing the conversation on larger organizations, this seems to blame
larger organizations for rising prices and says smaller organizations have
more immediate needs. If we want smaller organizations with two /24s and
only one used to be able to justify a transfer of a /24, we need to accept
organizations with two /8s justifying the transfer of a /8. It's only
fair.  If we want to change everything to 80%, I'm okay with that, but how
does that impact the situation as described in the inquiry?

We could set a maximum transfer unit, change the percentage, or whatever.
> But unless someone has a way to detect futures contracts and make them
> illegal, it's not going to be that hard to work around any changes to the
> policy that we make.
>
>
> Sadly, this is true as well (though I think illegal is the wrong term
> here… PPML doesn’t make law, we make registry policy.). However, just
> because a policy isn’t 100% enforceable, doesn’t mean it shouldn’t exist.
> Virtually none of our policies are 100% enforceable. The vast majority of
> policy, like the vast majority of law depends mostly on voluntary
> compliance… Keeping honest people honest, so to speak.
>

Yeah, illegal isn't right, but unless we can make it a policy violation of
some kind to enter into futures contracts, I don't see how changes are
going to be effective. Enforceable or not, nothing in the current policy
limits or even discourages futures contracts.


> We have the current policy because we wanted to make it easy for the small
> and medium guys to justify sizable blocks if they can justify them
> financially, as the market would add financial justification to the overall
> criteria.
>
> Yes, the same holds true for the big guys. Why shouldn't it? From a
> relative perspective, it's not any easier for the big guys. Their size
> and the absolute values involved just make it sound easier, but it's not.
>
>
> Because at each level, 16x as much space comes for 2x the price… The big
> guys are effectively getting a huge discount on dominating the market.
> True, that rule doesn’t apply to transfer pricing… In fact, the inverse
> used to be true (A /17 currently goes for about $43/address, but a provider
> that needs and qualifies for a /17 can still buy as many /24s as they want
> since we eliminated the single prefix provisions).
>

You are mixing fees and the market price. Big or small, ARIN's fees are
only a very small part of the equation.

> Yes, the market is driving up the price for IPv4. That is what we
> expected. The answer is for people to start using IPv6. Not for us to try
> to manipulate the IPv4 marketplace by trying to pick winners and losers.
>
>
> I don’t think shifting the requirement for ALL organizations back up to
> 80% instead of 50% is picking winners or losers.
>

Yes, but I don't think it will change the situation as it is described in
the inquiry.

> The rules are the rules, and let's have one set of rules: big, medium, or
> small.
>
>
> Absolutely agree with this. I’m not aware of any active proposal to do
> otherwise.
>

What about? "should utilization criteria be tied to the size of the org, in
other words tiered?"
That is not what is implied by that, at least in my opinion.

But I'm glad we agree the answer to that question is no.

> It's not that I oppose making any changes, but I don't think any changes
> are going to be effective and fundamentally change the fact that IPv4
&

Re: [arin-ppml] Re-thinking Section 8.5.6

[David Farmer via ARIN-PPML]

So, it sounds like we are talking about a policy aimed purely at ARIN
members in the 4XL and 5XL fee categories.

Furthermore, if an organization is large enough, the same statement could
be made even with an 80% threshold.
So, let's do the math; if an organization has 5 /8s at 80% full, that is a
/8 of free space.

Also, a similar statement, relatively speaking, could be made about anyone
in the XL or higher fee category having more than a /16 of free space.

We could set a maximum transfer unit, change the percentage, or whatever.
But unless someone has a way to detect futures contracts and make them
illegal, it's not going to be that hard to work around any changes to the
policy that we make.

We have the current policy because we wanted to make it easy for the small
and medium guys to justify sizable blocks if they can justify them
financially, as the market would add financial justification to the overall
criteria.

Yes, the same holds true for the big guys. Why shouldn't it? From a
relative perspective, it's not any easier for the big guys. Their size
and the absolute values involved just make it sound easier, but it's not.

Yes, the market is driving up the price for IPv4. That is what we expected.
The answer is for people to start using IPv6. Not for us to try to
manipulate the IPv4 marketplace by trying to pick winners and losers.

The rules are the rules, and let's have one set of rules: big, medium, or
small.

It's not that I oppose making any changes, but I don't think any changes
are going to be effective and fundamentally change the fact that IPv4
prices are going up and will continue to do so regardless of any policy
changes we make. More importantly, I'm worried that making changes at this
point will have unintended consequences.

Thanks.

On Thu, Jul 20, 2023 at 3:45 PM A N  wrote:

> On behalf of the ARIN AC Policy Experience Working Group, and in response
> to the Policy Implementation and Experience Report presented at ARIN 51,
> we're looking for input on a possible proposed revamp of NRPM Section 8.5.6
> "Efficient Utilization of Previous Blocks".
>
> The crux of the issue is there are very large orgs that could have a /8 or
> more of unused space, yet still qualify for more based on the current
> policy ("must have efficiently utilized at least 50%"). Smaller orgs with
> more immediate needs are in competition for the space, and prices are
> driven up.
>
> The Working Group would like some input on this before drafting a
> proposal. Input or thoughts are welcome about:
> - should the utilization be raised, and if so, to what threshold?
> - should utilization criteria be tied to the size of the org, in other
> words tiered?
> - any other thoughts.
>
> Thanks much!
> Anita
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2023-2: /26 initial IPv4 allocation for IXPs

[David Farmer via ARIN-PPML]

Oops, sorry the RIPE proposal number is 2023-01.

On Wed, Jun 21, 2023 at 08:15 David Farmer  wrote:

> Actually, I expect the genesis of this proposal was the very similar
> proposal in the RIPE community RIPE-2023-02 Reducing IXP IPv4 assignment
> default size to a /26. That proposal followed a presentation at RIPE 86
> last fall and a discussion on their address-policy-wg mailing late last
> year. The conversation started with a reduction to /29, and a reasonable
> compromise of /26 that was written in to a formal proposal earlier this
> year. That proposal is progressing through their process and just finished
> their Discussion Phase last week, and has entered their Review Phase, and
> at least seems to be heading towards being policy in the RIPE community.
>
> While I do not support this proposal, especially as written, it is
> nevertheless an important and timely conversation for the ARIN community to
> have and I for one appreciate it being brought forward to our community as
> a proposal.
>
> Thanks.
>
> On Wed, Jun 21, 2023 at 03:19 Matt Peterson  wrote:
>
>> It's clear this proposal did not receive feedback from those of us
>> who operate IXP's *(or those who lived through the ep.net
>>  era).* Renumbering events are often multi-year efforts
>> for an IXP, this "savings" is not worth the operational overhead. I'm not
>> in support of this proposal. This is a solution looking for a problem, we
>> have both the appropriate pool size and a method to refill.
>>
>> If anything, the 4.4 requirement language around *"other participants
>> (minimum of three total)" *could use some attention. ARIN's service
>> region has many "shadow IXP's", which may have 3 unique ASN's *(say a
>> route server, route collector, and management network) *- but are all
>> operated by the same organization. That does not seem like a legitimate
>> definition of an exchange point, especially when that operator is the only
>> participant over several years.
>>
>> --Matt
>>
>> On Tue, Jun 20, 2023 at 8:54 AM ARIN  wrote:
>>
>>> On 15 June 2023, the ARIN Advisory Council (AC) accepted “ARIN-prop-320:
>>> /26 initial IPv4 allocation for IXPs” as a Draft Policy.
>>>
>>> Draft Policy ARIN-2023-2 is below and can be found at:
>>>
>>> https://www.arin.net/participate/policy/drafts/2023_2
>>>
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>
>
>> --
> ===
> David Farmer   Email:far...@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===
>
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2023-2: /26 initial IPv4 allocation for IXPs

[David Farmer via ARIN-PPML]

Actually, I expect the genesis of this proposal was the very similar
proposal in the RIPE community RIPE-2023-02 Reducing IXP IPv4 assignment
default size to a /26. That proposal followed a presentation at RIPE 86
last fall and a discussion on their address-policy-wg mailing late last
year. The conversation started with a reduction to /29, and a reasonable
compromise of /26 that was written in to a formal proposal earlier this
year. That proposal is progressing through their process and just finished
their Discussion Phase last week, and has entered their Review Phase, and
at least seems to be heading towards being policy in the RIPE community.

While I do not support this proposal, especially as written, it is
nevertheless an important and timely conversation for the ARIN community to
have and I for one appreciate it being brought forward to our community as
a proposal.

Thanks.

On Wed, Jun 21, 2023 at 03:19 Matt Peterson  wrote:

> It's clear this proposal did not receive feedback from those of us
> who operate IXP's *(or those who lived through the ep.net 
> era).* Renumbering events are often multi-year efforts for an IXP, this
> "savings" is not worth the operational overhead. I'm not in support of this
> proposal. This is a solution looking for a problem, we have both the
> appropriate pool size and a method to refill.
>
> If anything, the 4.4 requirement language around *"other participants
> (minimum of three total)" *could use some attention. ARIN's service
> region has many "shadow IXP's", which may have 3 unique ASN's *(say a
> route server, route collector, and management network) *- but are all
> operated by the same organization. That does not seem like a legitimate
> definition of an exchange point, especially when that operator is the only
> participant over several years.
>
> --Matt
>
> On Tue, Jun 20, 2023 at 8:54 AM ARIN  wrote:
>
>> On 15 June 2023, the ARIN Advisory Council (AC) accepted “ARIN-prop-320:
>> /26 initial IPv4 allocation for IXPs” as a Draft Policy.
>>
>> Draft Policy ARIN-2023-2 is below and can be found at:
>>
>> https://www.arin.net/participate/policy/drafts/2023_2
>>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2023-2: /26 initial IPv4 allocation for IXPs

[David Farmer via ARIN-PPML]

So even if we go with 40 allocations per year, we have approximately 7
years of runtime in the current pool. Which is approximately the maximum
allocations in any year in the last 6 years and nearly double the average
for the same 6 years.

Given that analysis, I’m not inclined to require any IXP to accept less
that a /24.

However, I would encourage the IXP community to plan for the eventual
exhaustion of this pool by developing operational capabilities probably
based on RFC 8950 Advertising IPv4 Network Layer Reachability Information
(NLRI) with an IPv6 Next Hop or a similar capability yet unknown.

Thanks.


On Tue, Jun 20, 2023 at 17:06 Jason Byrne  wrote:

> David,
>
>
>
> For the number of /24s issued under NRPM 4.4 since 2018, we have the
> following stats (2023 data is year to date):
>
>
>
> 2018 – 18 /24s
>
> 2019 – 15 /24s
>
> 2020 – 21 /24s
>
> 2021 – 18 /24s
>
> 2022 – 39 /24s
>
> 2023 – 17 /24s
>
>
>
> Total currently remaining (as of 31 May 2023) in that reserved pool: 284
> /24s
>
>
>
> If you have any additional questions, please let us know.
>
>
>
> Regards,
>
>
>
> Jason Byrne
>
> Senior Customer Success Analyst
>
> ARIN
>
>
>
> *From: *ARIN-PPML  on behalf of David Farmer
> via ARIN-PPML 
> *Reply-To: *David Farmer 
> *Date: *Tuesday, June 20, 2023 at 1:53 PM
> *To: *Chris Woodfield 
> *Cc: *"arin-p...@lists.arin.net" 
> *Subject: *Re: [arin-ppml] Draft Policy ARIN-2023-2: /26 initial IPv4
> allocation for IXPs
>
>
>
> Before making a judgment on this policy, I would like to know how
> Micro-Allocations for IXPs have been made by ARIN in each of the last 6
> years.  Why 6 years? It’s twice the 3-years window of the replenishment
> policy.
>
>
>
> How much of the pool that is left is helpful to know. However, without
> also some idea of the current burn rate, it is difficult to make a
> realistic judgment regarding this policy.
>
>
>
> Thanks
>
>
>
> On Tue, Jun 20, 2023 at 12:10 Chris Woodfield  wrote:
>
> Speaking as the proposal author: It appears that a URL included in the
> draft language has been inadvertently eaten by formatting. The Statistics &
> Reporting link is here:
> https://www.arin.net/reference/research/statistics/#ipv4-reserved-pool-status-nrpm-4-10-ipv6-deployments
>
> I’ll also note that this page appears to have been updated since the
> policy was originally submitted - it now appears that the NPRM 4.4
> Micro-Allocation pool is 65% allocated, with 35% remaining. (There’s a good
> chance I was rounding down when I said 50% in the problem statement)
>
> Thanks,
>
> -Chris
>
> > On Jun 20, 2023, at 08:54, ARIN  wrote:
> >
> > On 15 June 2023, the ARIN Advisory Council (AC) accepted “ARIN-prop-320:
> /26 initial IPv4 allocation for IXPs” as a Draft Policy.
> >
> > Draft Policy ARIN-2023-2 is below and can be found at:
> >
> > https://www.arin.net/participate/policy/drafts/2023_2
> >
> > 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-2023-2: /26 initial IPv4 allocation for IXPs
> >
> > Problem Statement:
> >
> > Per NRPM Section 4.4, ARIN has reserved a /15 for micro-allocations for
> critical internet infrastructure, such as internet exchange points (IXPs)
> and core DNS service providers. The majority of these allocation requests
> are made by IXPs. As of the last ARIN report, roughly half of this
> reservation is allocated (see Statistics & Reporting  Projections from ARIN
> staff suggest that at current allocation rates, the remaining reserved
> space may be exhausted in the next few years.
> >
> > In parallel, an analysis of PeeringDB data conducted by the RIPE Address
> Policy Working Group shows that approximately 70% of global IXPs have fewer
> than 32 members registered with that site. An IXP this size could readily
> operate with a /26

Re: [arin-ppml] Draft Policy ARIN-2023-2: /26 initial IPv4 allocation for IXPs

[David Farmer via ARIN-PPML]

Before making a judgment on this policy, I would like to know how
Micro-Allocations for IXPs have been made by ARIN in each of the last 6
years.  Why 6 years? It’s twice the 3-years window of the replenishment
policy.

How much of the pool that is left is helpful to know. However, without also
some idea of the current burn rate, it is difficult to make a realistic
judgment regarding this policy.

Thanks

On Tue, Jun 20, 2023 at 12:10 Chris Woodfield  wrote:

> Speaking as the proposal author: It appears that a URL included in the
> draft language has been inadvertently eaten by formatting. The Statistics &
> Reporting link is here:
> https://www.arin.net/reference/research/statistics/#ipv4-reserved-pool-status-nrpm-4-10-ipv6-deployments
>
> I’ll also note that this page appears to have been updated since the
> policy was originally submitted - it now appears that the NPRM 4.4
> Micro-Allocation pool is 65% allocated, with 35% remaining. (There’s a good
> chance I was rounding down when I said 50% in the problem statement)
>
> Thanks,
>
> -Chris
>
> > On Jun 20, 2023, at 08:54, ARIN  wrote:
> >
> > On 15 June 2023, the ARIN Advisory Council (AC) accepted “ARIN-prop-320:
> /26 initial IPv4 allocation for IXPs” as a Draft Policy.
> >
> > Draft Policy ARIN-2023-2 is below and can be found at:
> >
> > https://www.arin.net/participate/policy/drafts/2023_2
> >
> > 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-2023-2: /26 initial IPv4 allocation for IXPs
> >
> > Problem Statement:
> >
> > Per NRPM Section 4.4, ARIN has reserved a /15 for micro-allocations for
> critical internet infrastructure, such as internet exchange points (IXPs)
> and core DNS service providers. The majority of these allocation requests
> are made by IXPs. As of the last ARIN report, roughly half of this
> reservation is allocated (see Statistics & Reporting  Projections from ARIN
> staff suggest that at current allocation rates, the remaining reserved
> space may be exhausted in the next few years.
> >
> > In parallel, an analysis of PeeringDB data conducted by the RIPE Address
> Policy Working Group shows that approximately 70% of global IXPs have fewer
> than 32 members registered with that site. An IXP this size could readily
> operate with a /26 allocation, which would provide 100% overprovisioning
> beyond their existing peer count. (Source:
> https://github.com/mwichtlh/address-policy-wg )
> >
> > Unlike other types of allocations, IXP peering networks are not required
> by member networks to be globally reachable; only members of the IXP must
> be able to reach the prefix. As such, there is no technical requirement
> that an IXP allocation must be no smaller than a /24.
> >
> > Policy statement:
> >
> > Existing text:
> >
> > 4.4. Micro-allocation
> >
> > ARIN will make IPv4 micro-allocations to critical infrastructure
> providers of the Internet, including public exchange points, core DNS
> service providers (e.g. ICANN-sanctioned root and ccTLD operators) as well
> as the RIRs and IANA. These allocations will be no smaller than a /24.
> Multiple allocations may be granted in certain situations.
> >
> > Replace with:
> >
> > 4.4 Micro-allocation
> >
> > ARIN will make IPv4 micro-allocations to critical infrastructure
> providers of the Internet, including public internet exchange points
> (IXPs), core DNS service providers (e.g. ICANN-sanctioned root and ccTLD
> operators) as well as the RIRs and IANA. These allocations will be no
> smaller than a /26 for IXPs, or a /24 for other allocations that require
> global reachability of the assigned allocation. Multiple allocations may be
> granted in certain situations.
> >
> > 4.4.1 Micro-allocations for Internet Exchange Points (IXPs)
> >
> > An IXP requesting an initial IPv4 allocation from this reserved space
> will be assigned a /26 by default. An IXP requesting an allocation larger
> than a /26 must show an immediate need to utilize more than 25% of the
> requested allocation size upon initial commissioning.
> >
> > An IXP requesting an allocation under this section must have also
> requested, or already received, an IPv6 allocation for the same purpose
> under Section 6.10.1.
> >
> > An allocation made to an IXP under this section may only be used for the
> operation of its public 

Re: [arin-ppml] implementing RPKI prefix validation actually increases risk

[David Farmer via ARIN-PPML]

Isn’t this why there is SLURM, RFC 8416, I think you should be able to
cause the RTBH feeds to be locally Valid from an RPKI point of view and
then prefer them in BGP. I think you could create 0.0.0.0/0 with max prefix
length 32 ROA for the RTBH feed ASNs. That or two /1 prefixes with a max
prefix length 32 ROAs, should do the trick, if I’m understanding your issue
correctly.

Hope that helps.

On Mon, Jun 5, 2023 at 21:29 Michel Py via ARIN-PPML 
wrote:

> Hi folks,
>
>
>
> I am bumping into a dark side of RPKI prefix validation that actually
> increases risk to the network when deployed.
>
>
>
> As many others here do, I use BGP blackhole feeds (RTBH). This technique
> has been around for a long time.
>
> It is quite a common situation in some orgs to have the in-house SIEM/IDS
> redistribute blackhole prefixes via a BGP feed.
>
> Also, there are numerous publicly available ones such as :
>
>
> https://team-cymru.com/community-services/bogon-reference/bogon-reference-bgp/
>
> https://www.spamhaus.org/bgpf/
>
> http://arneill-py.sacramento.ca.us/cbbc/
>
>
>
> When configuring RPKI validation, here is what happens. 152.89.196.0/24
> is a real-world example of a prefix that has been blacklisted by three
> different RTBH feeds.
>
> After implementing RPKI validation, it has generated some volume of
> firewall alarms for different type of attacks.
>
>
>
> c4321-michel#sh ip bgp | beg 152.89.196.
>
> BGP table version is 48156064, local router ID is 173.166.233.21
>
> Status codes: s suppressed, d damped, h history, * valid, > best, i -
> internal,
>
> Origin codes: i - IGP, e - EGP, ? - incomplete
>
> RPKI validation codes: V valid, I invalid, N Not found
>
>   Network  Next HopMetric LocPrf Weight Path
>
> I*152.89.196.0/24  192.0.2.10 90  0 21719 I
>  <== Trusted RTBH
>
> N* i   192.0.2.1 100  1 i
><== CBBC
>
> I* 192.0.2.10 40  0 65190 i
>  <== Spamhaus
>
> V*>173.166.233.22 30  0 1299 9002
> 57523 i<== Prefix from full feed
>
>
>
> The problem here is that RPKI validation is at the very top of the BGP
> bestpath decision process, before weight and local-preference, without any
> way to change that.
>
> Therefore, the “Valid” status of the RPKI route affectively renders the
> RTBH feeds useless. No matter what manipulations of other parameters may be
> configured in route-maps, the RPKI status will override everything else.
>
> Unsurprisingly, Cisco says that doing something about it is impossible.
>
>
>
> Unfortunately, the “Valid” RPKI status presents no warranties whatsoever
> that the prefix is not used for rogue activities. Same as HTTPS
> certificates, crooks and spammers have realized that a ROA was a necessary
> part of doing their dirty business.
>
> This particular prefix is a well-known source of attacks; there are very
> valid reasons it is present in multiple BGP blackholes. Unfortunately, RPKI
> validation, combined with Cisco’s implementation, as provided bad actors
> with a tool to disable a blacklisting method that plenty of orgs are
> currently using.
>
>
>
> I am forced to disable RPKI prefix validation. To me, RPKI prefix
> validation does not bring enough value to compensate for the loss of the
> protection that the BGP blackhole feeds provide. Implementing RPKI
> validation has actually increased the volume of attacks on my network,
> attacks that were previously blocked right at the very edge. The risk
> increase is immediate : implementing RPKI validation is what made me look
> at these new firewall alarms. On the other hand, the gain is not
> immediately perceptible.
>
>
>
> In terms of public policy and ARIN, I think that there is a consensus that
> deploying RPKI validation is good for everyone. I am posting this so that
> the community can build an understanding of why it may not be deployed
> universally. I am not deploying it because I don’t want it or don’t
> understand it, I am not deploying it because it simply does not work for
> me. I don’t think I will be the only one in that case. It looked like a
> good idea on paper, but the impossibility to accommodate currently
> implemented security measures is a no-go.
>
>
>
> Michel
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   

Re: [arin-ppml] Tenfold fee increases?

[David Farmer via ARIN-PPML]

Let’s be honest; the original $100 was just a number thrown out because
ARIN knew it had to charge something but didn’t have a good idea what the
real costs would be. The $1,000 number seems very reasonable to me, maybe
even low. At $10,000, I have a small amount of sympathy for an argument
that could be too high. Nevertheless, I trust the people we have put on the
board, and if they tell me that’s the right number, I’m inclined to let
things play out.

IP Brokers aren’t the only ones seeing ARIN fee increases. Some former
end-users have also seen very large fee increases in recent years. Further,
with the Legacy fee cap going away at the end of the year that will be
effectively a very massive fee increase for some.

All that said, I couldn’t find any justification for the increase from
$1,000 to $10,000. If there is justification or other details regarding the
increase, I’d appreciate a pointer to them.

Thanks

On Thu, Jun 1, 2023 at 15:32 Tom Fantacone  wrote:

> I was a bit stunned this morning to see our organization's ARIN fees
> would be going up by a factor of 10.  We live in inflationary times,
> but that's an increase of, let's see, I guess 1,000%?
>
> Before the rest of you resource holders on the list have a coronary,
> let me qualify that this fee increase is for just for registered
> facilitators (brokers) and most of you won't be affected.  This
> time.  But the more general issue of ARIN raising fees in an
> extravagant manner with no solicitation for public discussion of the
> impact affects all of us.
>
> When ARIN began the facilitators' program the annual fee was just
> $100.  A few years later the fee was raised tenfold to $1,000.  Today
> we learned that another tenfold increase would go into effect making
> our annual fee $10,000.  So it's actually a 100-fold increase in
> about a decade.
>
> Our own organization won't be too affected by this.  We can handle
> it, and most of the larger IP brokers can as well.  It may even help
> us by driving away some competition.  But that shouldn't be the
> point.  There are smaller organizations that are facilitators that
> will be severely impacted.  We work with some of these and while they
> may not handle the volume of transactions we do, they do an excellent
> job in moving IPv4 resources to organizations that need them and
> educating the parties along the way.
>
> There are some other changes to the facilitator program, including
> requiring liability insurance for ARIN, background checks, customer
> references, etc.  I assume this is to keep some of the riff-raff out
> and may be helpful.  I don't see how outrageous fee increases help anyone.
>
> Other sharp fee increases have been brought up and complained about
> on this list, always after the fact.  The recent resource holder fee
> increases that saw end user organizations suddenly treated as ISPs
> comes to mind.  Recently, transfer fees spiked from $300 to $500 per
> transfer and were suddenly appled to source organizations in all
> transfers (it used to be just transfers from end user orgs).  As if
> that wasn't enough, ARIN started charging transfer recipients an
> additional transfer fee.  I can tell you from first-hand experience
> this hurt small organizations looking to acquire IPv4 blocks.
>
> I recommend ARIN transparently solicit public input when pondering
> fee increases of such magnitude.  Hopefully before our fee goes up
> another 1,000%.
>
> Regards,
>
> Tom Fantacone
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Policy Experience Report Working Group Leasing Question

[David Farmer via ARIN-PPML]

It’s easy you you and me to say someone else would be better off buying a
/24 at ~$10K on the transfer market, than leasing it from their transit
provider or a third party. I tend to agree with that, but it’s not my
money, so maybe my opinion doesn’t matter.

On Mon, May 8, 2023 at 20:36 Michael B. Williams <
michael.willi...@glexia.com> wrote:

> I don’t believe third party leasing at a /24 or higher is in anyone’s best
> interest expect IP brokers and those obtaining IP resources with the intent
> to resell.
>
> I’m not against portability but if a participant wants portability they’d
> need a /24 or higher. Aquire their own IP resources…
>
> On Mon, May 8, 2023 at 21:30 David Farmer via ARIN-PPML <
> arin-ppml@arin.net> wrote:
>
>> At one time you couldn’t take your Telephone number with you provider to
>> provider, those rules were changed, because it was in the telephone
>> consumer’s interest.
>>
>> Can you consider that maybe it is in the Internet consumer’s to make some
>> changes to the IPv4 address leasing rules at this time. I’m not suggesting
>> full Internet address portability, but allowing 3rd party leasing
>> especially at the /24 level could be beneficial to the Internet consumer’s
>> interest, at least in my opinion.
>>
>> There are bigger picture issues at play in this conversation, should they
>> win the day, maybe not, but dismissing them out of had isn’t a good idea
>> either.
>>
>> Thanks.
>>
>> On Mon, May 8, 2023 at 20:06 Fernando Frediani 
>> wrote:
>>
>>> On 08/05/2023 21:54, David Farmer wrote:
>>>
>>> 
>>>
>>> In my opinion, your very technical definition of leasing is an
>>> anachronism. The reality is if you want/need more than a /29 of addresses,
>>> and you don’t already have them, you will need to pay for them one way or
>>> another on top of your transit bandwidth, through the transfer market,
>>> leasing them from your transit provider, or leasing them from a 3rd party,
>>> this is today’s reality, like it or not.
>>>
>>> Getting it from the transit provider who is building Internet
>>> infrastructure and providing connectivity is fine, has always been. Getting
>>> from a 3rd party who is just speculating around IP space and not interested
>>> in building any Internet stuff not. It does not matter what reality may be
>>> happening in some places, if that is wrong it does not make it look right
>>> because some are doing and find that a normal thing because it fits to
>>> their commercial needs. Is Congress willing to change law to make crimes in
>>> the top of list not to be a crime anymore because that is happening more
>>> often?
>>> You are only authorized to trade with what you bought and own.
>>>
>>> Fernando
>>>
>>>
>>> Thanks
>>>
>>> On Mon, May 8, 2023 at 18:23 Fernando Frediani 
>>> wrote:
>>>
>>>> Hi Willian. A customer who holds an ASN and is a ARIN member should not
>>>> get IP space to announce with their own ASN from the ISP provider but
>>>> directly with ARIN in all cases.
>>>> Legal risk will always exists and it is not because it exists it should
>>>> not be taken, just need to evaluated and worked.
>>>>
>>>> There has been a proposal presented not much a while ago that intended
>>>> to get that separation better worded and which was still in the process of
>>>> getting feedback and improvements, but AC quickly dismissed it in a
>>>> questionable way despite there has been people interested in discussing and
>>>> improving it. A pity. There has not even been a chance to get a improved
>>>> text in that sense.
>>>> And honestly there will always be some way someone will find out to try
>>>> to circumvent rules and I don't think there will be a perfect text, but a
>>>> reasonable one that can cover most scenarios can play a important role in
>>>> reducing scenarios where resources can be misused.
>>>> On 08/05/2023 19:45, William Herrin wrote:
>>>>
>>>> On Mon, May 8, 2023 at 3:26 PM Fernando Frediani  
>>>>  wrote:
>>>>
>>>> Another thing which many here are targeting about IP leasing
>>>> in the sense of renting, speculation made by those who don't
>>>> build or offer any Internet infrastructure and services. In other
>>>> words someone holding IP space and not using it to build any
>>>> Internet infrastructure and 

Re: [arin-ppml] Policy Experience Report Working Group Leasing Question

[David Farmer via ARIN-PPML]

At one time you couldn’t take your Telephone number with you provider to
provider, those rules were changed, because it was in the telephone
consumer’s interest.

Can you consider that maybe it is in the Internet consumer’s to make some
changes to the IPv4 address leasing rules at this time. I’m not suggesting
full Internet address portability, but allowing 3rd party leasing
especially at the /24 level could be beneficial to the Internet consumer’s
interest, at least in my opinion.

There are bigger picture issues at play in this conversation, should they
win the day, maybe not, but dismissing them out of had isn’t a good idea
either.

Thanks.

On Mon, May 8, 2023 at 20:06 Fernando Frediani  wrote:

> On 08/05/2023 21:54, David Farmer wrote:
>
> 
>
> In my opinion, your very technical definition of leasing is an
> anachronism. The reality is if you want/need more than a /29 of addresses,
> and you don’t already have them, you will need to pay for them one way or
> another on top of your transit bandwidth, through the transfer market,
> leasing them from your transit provider, or leasing them from a 3rd party,
> this is today’s reality, like it or not.
>
> Getting it from the transit provider who is building Internet
> infrastructure and providing connectivity is fine, has always been. Getting
> from a 3rd party who is just speculating around IP space and not interested
> in building any Internet stuff not. It does not matter what reality may be
> happening in some places, if that is wrong it does not make it look right
> because some are doing and find that a normal thing because it fits to
> their commercial needs. Is Congress willing to change law to make crimes in
> the top of list not to be a crime anymore because that is happening more
> often?
> You are only authorized to trade with what you bought and own.
>
> Fernando
>
>
> Thanks
>
> On Mon, May 8, 2023 at 18:23 Fernando Frediani 
> wrote:
>
>> Hi Willian. A customer who holds an ASN and is a ARIN member should not
>> get IP space to announce with their own ASN from the ISP provider but
>> directly with ARIN in all cases.
>> Legal risk will always exists and it is not because it exists it should
>> not be taken, just need to evaluated and worked.
>>
>> There has been a proposal presented not much a while ago that intended to
>> get that separation better worded and which was still in the process of
>> getting feedback and improvements, but AC quickly dismissed it in a
>> questionable way despite there has been people interested in discussing and
>> improving it. A pity. There has not even been a chance to get a improved
>> text in that sense.
>> And honestly there will always be some way someone will find out to try
>> to circumvent rules and I don't think there will be a perfect text, but a
>> reasonable one that can cover most scenarios can play a important role in
>> reducing scenarios where resources can be misused.
>> On 08/05/2023 19:45, William Herrin wrote:
>>
>> On Mon, May 8, 2023 at 3:26 PM Fernando Frediani  
>>  wrote:
>>
>> Another thing which many here are targeting about IP leasing
>> in the sense of renting, speculation made by those who don't
>> build or offer any Internet infrastructure and services. In other
>> words someone holding IP space and not using it to build any
>> Internet infrastructure and services.
>>
>> Hi Fernando,
>>
>> You may be missing my point. How do you differentiate in policy between:
>>
>> Scenario 1: ISP A provides a T1 and a /24. ISP B provides a gigabit
>> ethernet. Customer routes with BGP on both but depreferences ISP A so
>> it never shows up in the Internet BGP tables.
>>
>> Scenario 2: Pretextual ISP C (the defacto address leaser) provides a
>> /24 and a VPN (or virtual machine other nil-cost transit consuming
>> mechanism). ISP D provides a gigabit ethernet. Customer routes with
>> BGP on both but depreferences ISP C so it never shows up in the
>> Internet BGP tables.
>>
>> Scenario 1 is considered reasonable and has been for the entire
>> lifetime of the RIRs.
>>
>> Scenario 2 is the objectionable address leasing arrangement with a
>> tiny bit of fluff to bring it into technical compliance with ARIN
>> policy.
>>
>>
>> You can't tell ARIN to just exercise their judgement whether something
>> is defacto leasing. That creates legal risk to the organization where
>> they can't effectively act against the people they "know" to be
>> leasers.
>>
>> You have to write a policy that outright breaks scenario #2 without
>> harming scenario #1.That's the utilization count approach. ISP A in
>> scenario #1 is not particularly bothered if ARIN gets a bee in their
>> bonnet about counting that /24 utilized. So they have to be at 81%
>> instead of 80%. Same difference.
>>
>> ISP C in scenario #2, that's their entire business. If ARIN counts it
>> unutilized, they're out of business.
>>
>> Get it?
>>
>> Regards,
>> Bill Herrin
>>
>>
>> ___
>> ARIN-PPML
>> You are 

Re: [arin-ppml] Policy Experience Report Working Group Leasing Question

[David Farmer via ARIN-PPML]

Fernando,

You are using a very technical definition of leasing, and at least
historically you are correct.

However, with IPv4 runout the market place has changed significantly.
For example, I recently worked on a national scale RFP for the research and
education community, as part of it we asked the respondents about pricing
for IPv4 blocks provided with their DIA Internet services, consistent with
your view of how IP addresses should be provided. The responses ranged from
$1 - $5 per IPv4 address per month for midsized blocks (/28 - /26) and $.30
- $5 per IPv4 address per month for larger blocks (/25 - /21).

That a range of $600 to $10k a month for a /21, just for addresses and on
top of the transit bandwidth charges, and only half of the respondents
would even provide a block that big, the other half wouldn’t provide any
blocks bigger than a /24.

So, when I say all ISP are leasing addresses, this is the market reality
I’m referring too. The very technical definition of leasing you are talking
about has been overtaken by the facts of the IPv4 address market place.

In my opinion, your very technical definition of leasing is an anachronism.
The reality is if you want/need more than a /29 of addresses, and you don’t
already have them, you will need to pay for them one way or another on top
of your transit bandwidth, through the transfer market, leasing them from
your transit provider, or leasing them from a 3rd party, this is today’s
reality, like it or not.

Thanks

On Mon, May 8, 2023 at 18:23 Fernando Frediani  wrote:

> Hi Willian. A customer who holds an ASN and is a ARIN member should not
> get IP space to announce with their own ASN from the ISP provider but
> directly with ARIN in all cases.
> Legal risk will always exists and it is not because it exists it should
> not be taken, just need to evaluated and worked.
>
> There has been a proposal presented not much a while ago that intended to
> get that separation better worded and which was still in the process of
> getting feedback and improvements, but AC quickly dismissed it in a
> questionable way despite there has been people interested in discussing and
> improving it. A pity. There has not even been a chance to get a improved
> text in that sense.
> And honestly there will always be some way someone will find out to try to
> circumvent rules and I don't think there will be a perfect text, but a
> reasonable one that can cover most scenarios can play a important role in
> reducing scenarios where resources can be misused.
> On 08/05/2023 19:45, William Herrin wrote:
>
> On Mon, May 8, 2023 at 3:26 PM Fernando Frediani  
>  wrote:
>
> Another thing which many here are targeting about IP leasing
> in the sense of renting, speculation made by those who don't
> build or offer any Internet infrastructure and services. In other
> words someone holding IP space and not using it to build any
> Internet infrastructure and services.
>
> Hi Fernando,
>
> You may be missing my point. How do you differentiate in policy between:
>
> Scenario 1: ISP A provides a T1 and a /24. ISP B provides a gigabit
> ethernet. Customer routes with BGP on both but depreferences ISP A so
> it never shows up in the Internet BGP tables.
>
> Scenario 2: Pretextual ISP C (the defacto address leaser) provides a
> /24 and a VPN (or virtual machine other nil-cost transit consuming
> mechanism). ISP D provides a gigabit ethernet. Customer routes with
> BGP on both but depreferences ISP C so it never shows up in the
> Internet BGP tables.
>
> Scenario 1 is considered reasonable and has been for the entire
> lifetime of the RIRs.
>
> Scenario 2 is the objectionable address leasing arrangement with a
> tiny bit of fluff to bring it into technical compliance with ARIN
> policy.
>
>
> You can't tell ARIN to just exercise their judgement whether something
> is defacto leasing. That creates legal risk to the organization where
> they can't effectively act against the people they "know" to be
> leasers.
>
> You have to write a policy that outright breaks scenario #2 without
> harming scenario #1.That's the utilization count approach. ISP A in
> scenario #1 is not particularly bothered if ARIN gets a bee in their
> bonnet about counting that /24 utilized. So they have to be at 81%
> instead of 80%. Same difference.
>
> ISP C in scenario #2, that's their entire business. If ARIN counts it
> unutilized, they're out of business.
>
> Get it?
>
> Regards,
> Bill Herrin
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information 

Re: [arin-ppml] Policy Experience Report Working Group Leasing Question

[David Farmer via ARIN-PPML]

I’m no lawyer, but 501c14s, state chartered credit unions, and 501c6s,
business leagues and how ARIN is organized, have significantly different
purposes and rules. Could ARIN auction the waiting list resources, maybe,
but it’s likely to be the cause for a significant review by the IRS. With
such a review, there is a risk, significant in my opinion, the auction
could be ruled a non-exempt business activity, and risk ARIN’s tax exempt
status. In any case, this is really a matter for the ARIN board and not
really a policy discussion.

Thanks.

On Sun, May 7, 2023 at 18:55 Michel Py 
wrote:

> Hi David,
>
> > David Farmer wrote :
> > Suggestions that ARIN should instead auction the waiting list resources,
> while seemingly logical, given
> > the success of the transfer market, nevertheless seem incompatible with
> ARIN's not-for-profit status.
>
> I have to disagree with that. I work for a Credit Union, that some people
> call a not-for-profit bank.
> We do not have publicly traded shares, and obviously we do not pay
> dividends to shareholders. _That_ would be profit.
> However, we do make money. Revenue, which is not the same thing as profit.
> If you were to have a loan to buy a car or a mortgage to acquire a house,
> not only you would have to pay it back, but you'd also have to pay us
> interest. We are a non-profit, not a charity, we do not give free money
> away and we even make money on financial markets. That is how we pay our
> bills and our employees. It's not greed, but we do have to make a buck like
> everyone else including ARIN.
>
> There is nothing wrong for a non-profit to make money. ARIN does make
> money : we pay fees. How that money is used could (and should) indeed be
> questioned, if it was used to lower member fees or pay for expenses, I
> don't see any fundamental problem with ARIN charging $38 (or whatever the
> market is) per IP as a fee to transfer space that would become available or
> reclaimed.
>
> Now, let's hypothesize that 240/4 becomes available for public routing
> unicast allocation and that ARIN gets a /6 out of it, 67 million IP at $38
> a pop would be 2 billion and change, then that would be a different issue.
> If the waiting list was to disappear, it would be wise to have some
> language that Class E suddenly becoming available would not be auctioned
> out.
> But given what I would call a trickle that the waiting list currently is,
> I don't see a problem.
>
> Michel
>
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Policy Experience Report Working Group Leasing Question

[David Farmer via ARIN-PPML]

In my opinion, the 60-month probation on transfers in section 4.1.8 is
intended to prevent immediate monetization through the transfer market of
IPv4 resources obtained from the waiting list. Allowing the lease of IPv4
resources obtained from the waiting list prior to the end of the 60-month
probation would seem to flaunt the intent of the probation. However, once
past the 60-month probation, allowing the transfer or lease of IPv4
resources seems consistent with the policies intent.

I would like to point out that the transfer market has been remarkably
successful in making IPv4 resources voluntarily available that otherwise
would not have been available or would have required a highly
litigious reclamation process to be made available. In addition, leasing
seems to be a natural evolution of the transfer market for those that do
not have the capital funding to obtain IPv4 resources on the transfer
market. Finally, despite a few issues, the waiting list has also been
remarkably successful at ensuring any IPv4 resources returned to ARIN, for
whatever reason, are redistributed to the ARIN community.

Suggestions that ARIN should instead auction the waiting list resources,
while seemingly logical, given the success of the transfer market,
nevertheless seem incompatible with ARIN's not-for-profit status.

In summary, leasing IPv4 resources obtained from the waiting list after
the 60-month probation should be allowed. Prior to that, leasing should not
be allowed. How we effectively enforce that is another question entirely,
and I personally don't have any good answers to that question.

Thanks

On Fri, May 5, 2023 at 10:54 AM WOOD Alison * DAS <
alison.w...@das.oregon.gov> wrote:

> Good morning PPML!
>
>
>
> I would like community feedback on the leasing of ip space that is
> obtained from the waitlist.  Please let me know what you think and if a
> policy proposal would be warranted.
>
>
>
> Thank you!
>
>
>
> -Alison
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2022-11: Clean-up of NRPM – Introduction of Section 2.17

[David Farmer via ARIN-PPML]

I support the policy as written and moving it forward to the board.

However, I hope my suggestion to modify the opening paragraph of section
2 will be taken up as a separate proposal. I think it would knit the
definitions and the diagram in the opening of section 2 together. Right now
the opening paragraph and the diagram seem only tangentially related to the
definitions that follow.

Thanks

On Mon, Apr 24, 2023 at 12:41 PM Edward Diego  wrote:

> The ARIN Advisory Council (AC) met on 19 April 2023, and sent the
> following Recommended Draft Policy to Last Call for an extended period with
> communication sent from staff:
>
>
>
> * Recommended Draft Policy ARIN-2022-11: Clean-up of NRPM – Introduction
> of Section 2.17
>
>
>
> ARIN staff confirms the correct Recommended Draft Policy text was
> communicated to PPML on 16 March 2023 and again on 21 March 2023. The
> appropriate text was presented at ARIN 51 on 17 Apr 2023 which received
> community support. It has been noted
> https://www.arin.net/participate/policy/drafts/2022_11/ on ARIN’s website
> did not exactly match the text sent to PPML or the text presented at ARIN
> 51. ARIN’s website has been corrected, and ARIN staff apologizes for any
> confusion this may have caused.
>
>
>
> Feedback is encouraged during the Last Call period. All comments should be
> provided to the Public Policy Mailing List. Last Call will expire on 9 Jun
> 2023.
>
>
>
> The Recommended Draft Policy text is below and available at:
>
>
>
> *https://www.arin.net/participate/policy/drafts/2022_11/
> *
>
>
>
> The ARIN Policy Development Process is available at:
>
> *https://www.arin.net/participate/policy/pdp/
> *
>
>
>
> Regards,
>
>
>
> Eddie Diego
>
> Policy Analyst
>
> American Registry for Internet Numbers (ARIN)
>
>
>
>
>
>
>
> Recommended Draft Policy ARIN-2022-11: Clean-up of NRPM – Introduction of
> Section 2.17
>
>
>
> AC Assessment of Conformance with the Principles of Internet Number
> Resource Policy:
>
>
>
> Based on community feedback and AC discussion we motion to move
> ARIN-2022-11: Clean-up of NRPM – Introduction of Section 2.17 to
> Recommended Draft, with the following definition: “Internet number
> resources are unique identifiers within the Internet Numbers Registry
> System [as described in IETF RFC 7020] and this includes ranges (or
> “blocks”) of contiguous Internet Protocol (“IP”) addresses and Autonomous
> System Numbers (“ASNs”).” This Draft Policy is fair, impartial, and
> technically sound and will add clarity to the term “Internet number
> resources”.
>
>
>
> Problem Statement:
>
>
>
> The term Internet Number Resources is referenced in several sections of
> the NRPM but is not defined.
>
>
>
> Policy Statement:
>
>
>
> “Internet number resources are unique identifiers within the Internet
> Numbers Registry System [as described in IETF RFC 7020] and this includes
> ranges (or “blocks”) of contiguous Internet Protocol (“IP”) addresses and
> Autonomous System Numbers (“ASNs”).”
>
>
>
> Timetable for Implementation: Immediate
>
>
>
> Comments:
>
>
>
> Although this proposal was drafted in the course of an editorial review of
> Section 2 of the NRPM, the addition of a new definition may not be
> considered purely editorial in nature and so this proposal is not being
> presented as strictly editorial.
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] IPv6 Multiple Discrete Networks

[David Farmer via ARIN-PPML]

Owen,

Subsequent allocations for multi discrete end-users are discussed in
section 6.5.8.3. So, while the organization of things might be unusual, I
think it’s all covered.

On Fri, Apr 7, 2023 at 17:54 Owen DeLong via ARIN-PPML 
wrote:

> I was reviewing 6.11 (because my organization is probably about to apply
> for some assignments under this clause), and I discovered an interesting
> oversight.
>
> It won’t affect our initial application, but 6.11.7 specifically lists
> utilization being judged against 6.5.2 and 6.5.3, but leaves out 6.5.8,
> implying that only ISP Allocations can be the subject of an MDN request for
> additional space. Also, in terms of hierarchy, 6.11.6 and 6.111.7 should
> probably be 6.11.5.1 and 6.11.5.2, respectively.
>
> I wanted to get some feedback from the community and the AC first, but
> unless someone has a completely negative reaction, I’ll probably submit a
> formal proposal with the expectation that it is probably an editorial
> correction.
>
> I’d also be interested to hear from Sweeting if the current staff
> implementation of the policy would include users meeting 6.5.8 criteria or
> if they rigidly stick to 6.5.2 and 6.5.3 for this policy. Specifically, if
> the current implementation includes 6.5.8, then this could be an editorial
> change because it wouldn’t change how policy is currently carried out, but
> if it would change that, then it becomes a policy change which needs to go
> through the full process.
>
>
> Owen
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Recommended Draft Policy ARIN-2022-11: Clean-up of NRPM – Introduction of Section 2.17

[David Farmer via ARIN-PPML]

Yes, there are always trade-offs. Nevertheless, I still think the solution
to this problem requires a more holistic view of section 2.

Looking at this more, I have the following suggestion;

Rewrite the introductory paragraph to section 2 as follows;

Networks of all sizes and types require integers to identify devices within
the network. The global Internet requires identifiers that are globally
unique. These globally unique identifiers are known as Internet number
resources, consisting of Internet Protocol (IP) addresses, both versions
four (4) and six (6), and Autonomous System Numbers (ASNs). They are
globally distributed and managed hierarchically in accordance with the
following diagram;

Bullet list and diagram:

2.17  Internet number resources are unique identifiers within the Internet
Numbers Registry System [as described in IETF RFC 7020], and this includes
ranges (or blocks) of contiguous Internet Protocol (IP) addresses and
Autonomous System Numbers (ASNs).

Thanks

On Wed, Mar 22, 2023 at 12:23 PM William Herrin  wrote:

> On Wed, Mar 22, 2023 at 10:05 AM David Farmer  wrote:
> > When I look at section 2 as a whole, I believe the term Number
> > Resources logically belongs near the top of the list and not near the
> bottom of the list.
>
> Hi David,
>
> If you're just looking at the static document, you're right. But
> here's the thing: there are postings, tutorials and even books that
> refer to "section X.X of the ARIN NRPM." It's a whole ecosystem of
> knowledge. If you renumber the sections so that those references no
> longer line up, you contribute to the general chaos instead of making
> things easier to understand.
>
> It's like the problem of numbering the exits on the Interstate
> highways. If you just number them in order, 1 2 3 4 5, then whenever
> you add a new off-ramp you have to change all the numbers. Suddenly
> all the maps are wrong.
>
>
> > Further, if added to the top of the list, the added details of Bill's
> proposed definition seem much more appropriate to me.
>
> I appreciate the support!
>
> Regards,
> Bill
>
> --
> For hire. https://bill.herrin.us/resume/
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Recommended Draft Policy ARIN-2022-11: Clean-up of NRPM – Introduction of Section 2.17

[David Farmer via ARIN-PPML]

I support adding a definition for the term Number Resources to the
definitions in section 2 of the NRPM. However, I don't think it should be
identified as section 2.17, even though that is the next number for that
section. When I look at section 2 as a whole, I believe the term Number
Resources logically belongs near the top of the list and not near the
bottom of the list.

Further, if added to the top of the list, the added details of Bill's
proposed definition seem much more appropriate to me.

Finally, I suggest looking at section 2 as a whole, including the
introduction and diagram, then how and where the definition of the term
Number Resources is best added, and not just the text of the definition to
be added.

Thanks

On Wed, Mar 22, 2023 at 10:34 AM John Curran  wrote:

>
> On Mar 22, 2023, at 11:27 AM, William Herrin  wrote:
>
>
> Asked and answered. Perhaps you missed it the first two times around?
> ...
> https://lists.arin.net/pipermail/arin-ppml/2023-January/070202.html
>
>
> You propose -
>
> *Computer network protocols often use unique integers to identify*
> *computers and functions within the network. Examples include IP*
> *addresses in versions four and six of the Internet Protocol and*
> *Autonomous System Numbers in the Border Gateway Protocol. The Regional*
> *Internet Registries, including ARIN, manage the registration of such*
> *Number Resources by the organizations which use these network*
> *protocols, assuring that two organizations do not end up with the same*
> *numbers.*
>
>
> and then elsewhere suggest "The point of section 2 is to render technical
> jargon in
> terms of -ordinary English-."
>
> Alas, Number Resource Policy Manual is not intended as a primer on
> computer networking,
> and the point of section 2 is rather to provide technical definitions for
> a technical audience.
>
> Thanks,
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Advisory Council Meeting Results - December 2022

[David Farmer via ARIN-PPML]

I believe the status for ARIN-2022-13 below is inaccurate, it shows that
work will continue on the policy. However, item 13 in the draft minutes for
the 12/15 AC meeting, link below, clearly show that ARIN-2022-13 has been
abandoned.

https://www.arin.net/about/welcome/ac/meetings/2022_1215/

Further, the status page for ARIN-2022-13 show it has been abandoned;

https://www.arin.net/participate/policy/drafts/2022_13/

Thanks

On Wed, Dec 21, 2022 at 8:17 AM ARIN  wrote:

> In accordance with the Policy Development Process (PDP), the Advisory
> Council met on 15 December 2022.
>
> The AC has advanced the following to the Board of Trustees for review:
>
>
>
> * ARIN-edit-2022-10: Editorial Clean-up of NRPM Sections 2.4 and 2.5
>
>
>
> The AC is continuing to work on:
>
>
>
> Recommended Draft Policies:
>
>
>
> * ARIN-2021-8: Deprecation of the ‘Autonomous System Originations’ Field
>
> * ARIN-2022-2: Remove Barrier to BGP Uptake in ASN Policy
>
> * ARIN-2022-3: Remove Officer Attestation Requirement for 8.5.5
>
>
>
> Draft Policies:
>
>
>
> * ARIN-2022-4: Clean-up of NRPM Sections 2.1 and 2.2
>
> * ARIN-2022-5: Clean-up of NRPM Section 2.11
>
> * ARIN-2022-8: Streamlining Section 11 Policy Language
>
> * ARIN-2022-11: Clean-up of NRPM – Introduction of Sections 2.17 and 2.18
>
> * ARIN-2022-12: Direct Assignment Language Update
>
> * ARIN-2022-13: Clean-up of NRPM Section 2.10
>
>
>
> 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,
>
>
>
> Sean Hopkins
>
> Senior 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 (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Are we an ISP or an End-User? Can our designation change at a later time?

[David Farmer via ARIN-PPML]

On Wed, Jan 4, 2023 at 4:32 PM William Herrin  wrote:

> On Wed, Jan 4, 2023 at 11:52 AM Fernando Frediani 
> wrote:
> > Another thing that I wanted to understand better is the reasoning to
> allocate a significant smaller IPv6 block to a said end-user organization
> given it is not so scarce resource.
>
> The standard size assignment to an end user is /48 per IETF
> recommendation. That's 65,000 LANs, 2^80 IP addresses. Vanishingly few
> end-user organizations actually have a need for more LANs than that.
> However, since /48 is also the minimum Internet routable size,
> end-user organizations with multiple independently-connected sites may
> need several /48s. That's a minority of end-users but still a
> significant number.
>

This is all true; However, justifying a larger end-user allocation
(formerly known as an assignment) isn’t that hard either; you justify a /48
per site in a larger multi-site organization; they don’t have to be
independently connected. That is, more than 1 site but less than or equal
to 12 sites receive a /44 allocation; more than 12 but less than or equal
to 192 sites receive a /40 allocation; see the policy for even larger
allocations and a discussion for campus environments. Also, most larger
organizations likely could qualify as an ISP/LIR if they wish.

So, many end-user organizations are receiving /44s, /40s, and even larger
allocations without much trouble. Could the ARIN staff provide an
updated histogram of IPv6 allocation sizes; I haven't seen one in several
years.

I hope that helps.


> ISPs get a /32 so that, by default, they can assign 65,000 /48s to
> their customers and still keep a few for themselves. That's the reason
> they receive significantly more.
>
> Regards,
> Bill Herrin
>
> --
> For hire. https://bill.herrin.us/resume/
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2022-13: Clean-up of NRPM Section 2.10

[David Farmer via ARIN-PPML]

On Thu, Nov 17, 2022 at 12:13 PM ARIN  wrote:

> Draft Policy ARIN-2022-13: Clean-up of NRPM Section 2.10
>
>
>
> Problem Statement:
>
>
>
> As a result of ARIN’s fee harmonization direct assignments are no longer
> being utilized within ARIN databases therefore language around that has
> been deprecated and should be modernized.
>

It is unclear to me why the term "end site" and its use in the NRPM has
anything to do with ARIN’s fee harmonization or direct assignments, as
presented in the Problem Statement. The term "end site" is used in
section 6.5.2.1. in determining the size of initial allocations to LIRs and
in section 2.15. Provider Assignment Unit (IPv6), which itself is used in
section 2.16. Utilized (IPv6) and in section 6.5.2.1 as Provider Allocation
Unit.  Furthermore, section 6.5.8, Direct Assignments from ARIN to End-user
Organizations, which the problem statement seems most related to, uses the
simple term "sites" and not the defined term "end sites." But even if
section 6.5.8 used the term "end site," it is still unclear to me why it
needs to be changed.

Therefore, in my mind, the Problem statement and the proposed new Policy
Statement are mismatched. In my opinion, the current definition of "end
site" remains appropriate and should not be modified at all.

I do believe that section 2.15 should be retitled as "Provider Allocation
Unit," and the term should also be changed in the body of sections 2.15 and
2.16, and the current use of the term "Provider Allocation Unit" in section
6.5.2.1 is correct. However, it would probably be best for this to be a
separate proposal.

As for this proposal, if the term "end site" needs to be modified, the
Problem Statement needs to more clearly state what is wrong with the
currently defined term "end site" and how it is used within the NRPM.

Thanks.

Problem Statement:
>
>
>
> This proposal continues the work that the ARIN AC NRPM Clean-up Working
> Group undertook to conduct an editorial review of the NRPM. It relates
> specifically to Section 2.10. The focus of this proposal is to both clarify
> and simplify the wording of the section.
>
> Policy Statement:
>
> Replace the existing text: “The term End Site shall mean a single
> structure or service delivery address, or, in the case of a multi-tenant
> structure, a single tenant within said structure (a single customer
> location).”
>
> With the new text: “An End Site is the smallest subnet in a network
> requiring IPv6 address space.”
>
> Comments: None
>
> Timetable for implementation: Immediate.
>
> Anything else: This proposal is intended to replace ARIN-prop-305 in part,
> but is not considered strictly editorial in nature.
>

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Transferring Waiting List Space - Feedback Requested

[David Farmer via ARIN-PPML]

Conceptually, as an abstract idea, I have no problem with restricting the
waiting list to newcomers only. However, the implementation of such a
restriction could prove problematic; What is a true newcomer? How do we
prevent gaming of this restriction?

The current 60-month restriction on transfers is already functionally
indefinite, at least in my option.

Finally, the waiting list was never intended as a viable option to meet a
network's need for resources; its purpose in policy is to ensure ARIN has a
mechanism to distribute any IPv4 resources that are reclaimed or
otherwise become available to ARIN.

Thanks.

On Mon, Nov 14, 2022 at 5:09 PM Fernando Frediani 
wrote:

> Then need to detail and analyze what sound unreasonable in changing 5
> years period to indefinite.
>
> Reducing the request size to anything smaller than an /22 is giving a such
> small and useless space that will probably make no difference to whoever
> receives it. A /22 is already a very small amount (almost symbolic) but at
> least gives the ability to a newer organizations to work with something,
> get into the market, innovate, reach some proper size and then invest in
> different technologies to make better usage of few IPv4 and deploy IPv6
> properly in order to keep existing in the market. Plus giving out /24-only
> to organizations in the waiting list would contribute even more to increase
> the size of the routing table with very little gain.
>
> A change in the waiting-list rules that would be certainly be welcome is
> restrict it only to newcomers that have no IPv4 space at all. Those who
> already have had already enough time to learn live with what they have and
> organize themselves to either do IPv4 transfers and deploy IPv6 in order to
> reduce its dependency whenever possible.
>
> Fernando
> On 14/11/2022 19:53, David Farmer via ARIN-PPML wrote:
>
> I reviewed the Policy Implementation and Experience Report presented at
> ARIN 50;
>
>
> https://www.arin.net/participate/meetings/ARIN50/materials/1020_policyimplementation.pdf
>
> https://www.youtube.com/watch?v=RruDSG32D0M=PL726kQ53RX6i-x05T2JLckh59gWtLs1TR=5569s
>
> https://www.arin.net/participate/meetings/ARIN50/day1_transcript/#policy-implementation-and-experience-report
>
> I don't support any changes to the transfer provisions of the waiting
> list. The current transfer provisions seem reasonable to me.
>
> However, if I were going to support any changes to the waiting list, I
> would support reducing the request size from /22 to /24.
>
> Thanks.
>
> On Mon, Nov 14, 2022 at 3:42 PM WOOD Alison * DAS <
> alison.w...@das.oregon.gov> wrote:
>
>> Hello!
>>
>>
>>
>> The Policy Experience Report Working Group has been working on the Policy
>> Experience Report from ARIN 50.  I would appreciate your feedback on the
>> following issue regarding transferring waitlist space.
>>
>>
>>
>> The current wait list criteria is:
>>
>>
>>
>>- Must have a /20 or less in total IPv4 holdings.
>>- May request up to a /22.
>>- Removed from list if IPv4 received via 8.3/8.4 transfer.
>>- Received ip space is eligible for needs-based transfer after five
>>years.
>>
>>
>>
>>
>>
>> The Policy Experience Working Group would like your feedback on a
>> potential policy that would restrict the transfer of IP space that has been
>> obtained from the waiting list.  In other words, any IP address space
>> received from the waiting list would be ineligible for transfer
>> indefinitely and encouraged to be returned to ARIN if not in use.  This
>> policy would be specific to transfers and not M & A’s.
>>
>>
>>
>> The working group appreciates your feedback.
>>
>>
>>
>> Thank you!
>>
>>
>>
>>
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>
>
>
> --
> ===
> David Farmer   Email:far...@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===
>
> ___
> ARIN-PPML
> You are receiving this messa

Re: [arin-ppml] Transferring Waiting List Space - Feedback Requested

[David Farmer via ARIN-PPML]

I reviewed the Policy Implementation and Experience Report presented at
ARIN 50;

https://www.arin.net/participate/meetings/ARIN50/materials/1020_policyimplementation.pdf
https://www.youtube.com/watch?v=RruDSG32D0M=PL726kQ53RX6i-x05T2JLckh59gWtLs1TR=5569s
https://www.arin.net/participate/meetings/ARIN50/day1_transcript/#policy-implementation-and-experience-report

I don't support any changes to the transfer provisions of the waiting list.
The current transfer provisions seem reasonable to me.

However, if I were going to support any changes to the waiting list, I
would support reducing the request size from /22 to /24.

Thanks.

On Mon, Nov 14, 2022 at 3:42 PM WOOD Alison * DAS <
alison.w...@das.oregon.gov> wrote:

> Hello!
>
>
>
> The Policy Experience Report Working Group has been working on the Policy
> Experience Report from ARIN 50.  I would appreciate your feedback on the
> following issue regarding transferring waitlist space.
>
>
>
> The current wait list criteria is:
>
>
>
>- Must have a /20 or less in total IPv4 holdings.
>- May request up to a /22.
>- Removed from list if IPv4 received via 8.3/8.4 transfer.
>- Received ip space is eligible for needs-based transfer after five
>years.
>
>
>
>
>
> The Policy Experience Working Group would like your feedback on a
> potential policy that would restrict the transfer of IP space that has been
> obtained from the waiting list.  In other words, any IP address space
> received from the waiting list would be ineligible for transfer
> indefinitely and encouraged to be returned to ARIN if not in use.  This
> policy would be specific to transfers and not M & A’s.
>
>
>
> The working group appreciates your feedback.
>
>
>
> Thank you!
>
>
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Recommended Draft Policy ARIN-2021-8: Deprecation of the ‘Autonomous System Originations’ Field

[David Farmer via ARIN-PPML]

On Mon, Oct 31, 2022 at 9:47 PM Owen DeLong  wrote:

>
> While it’s true that ARIN does not make the authenticated IRR or RPKI
> available to legacy holders without a contract, those that care
> to publish the information are free to do any of the following:
> + Transfer their legacy resources to RIPE and publish RPKI there
> + Use ALT-DB or another IRR to publish their RPSL statements
>

Transferring your resources to RIPE will either require a contract with
RIPE if you wish to become an LIR or a contract with a sponsoring LIR. So,
you are probably not doing RPKI without some kind of contract. You may have
some choices on who you contract with, but I see a contract in your
future if you want to do RPKI.

As for ALT-DB that could be an option. However, if content providers start
requiring authenticated IRR information, which is being at least talked
about, then ALT-DB might only be a short-term option.


> I will admit that during the original debate, I opposed the creation of
> this field expecting that it would end up exactly where it is now. Of
> limited
> use and even less accuracy.
>
> IMHO, it’s well past time to recognize this as a failed experiment and
> clean up after it.
>

The experiment was not a failure, but we have better options now, so I
agree it's time for it to go.


> Owen
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Recommended Draft Policy ARIN-2021-8: Deprecation of the ‘Autonomous System Originations’ Field

[David Farmer via ARIN-PPML]

On Mon, Oct 31, 2022 at 7:36 PM Owen DeLong via ARIN-PPML <
arin-ppml@arin.net> wrote:

> The data is largely missing.
> What’s not missing is largely inaccurate.
>
> If anyone is relying on it for any purpose, that’s bad.
> If we take away the bad data, then we can be sure that nobody is relying
> upon it. That’s good.
>
> What am I missing?
>
> Owen
>

Additionally, as said in the problem statement of ARIN-2021-8 the ORIGIN-AS
field it is difficult to consume; there are better options now, ARIN's
authenticated IRR and RPKI. Furthermore, the field is not well-formed from
a data typing perspective; it's just a text field. Additionally, when you
have multiple sources of data, it is easy for those data sources to have
different and conflicting data. I believe long term the best thing to do is
to eliminate the ORIGIN-AS field in favor of the more well-formed and
authoritative data in ARIN’s authenticated IRR and in RPKI. Also, at the
ARIN 50 microphone, Rob Seastrom mentioned the policy that created this
field and Sandra Murphy's original slides; here are links to them;

https://www.arin.net/vault/policy/proposals/2006_3.html
https://www.arin.net/vault/participate/meetings/reports/ARIN_XVII/PDF/tuesday/2006-3-murphy.pdf
https://www.arin.net/vault/participate/meetings/reports/ARIN_XVIII/PDF/wednesday/2006-3_Murphy.pdf

The only question in my mind has been, what is the right timetable for
deprecating the ORIGIN-AS field? Currently, some legacy resource holders
don’t have access to ARIN’s authenticated IRR or to RPKI and only can use
the ORIGIN-AS field. However, with the recent changes to the RSA/LRSA and
the deadline to take advantage of the legacy fee cap, legacy resource
holders should be properly incentivized to sign an LRSA and resolve this
contracting issue well within the current timetable for implementation of
this policy. See the following ARIN Announcements;

https://www.arin.net/announcements/20220912/
https://www.arin.net/announcements/20220913/

I support this Recommended Draft Policy as written.

Thanks
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2022-8: Streamlining Section 11 Policy Language

[David Farmer via ARIN-PPML]

Oh, and updates that followed;

https://labs.ripe.net/author/emileaben/has-the-routability-of-longer-than-24-prefixes-changed/

https://labs.ripe.net/author/stephen_strowes/bgp-even-more-specifics-in-2017/


On Mon, Oct 31, 2022 at 17:43 David Farmer  wrote:

> Here is an example of an experimental allocation made by ARIN;
>
>
> https://labs.ripe.net/author/emileaben/propagation-of-longer-than-24-ipv4-prefixes/
>
> It is probably not a typical instance of such an allocation, but I’m not
> sure there is such a thing.
>
> Thanks
>
> On Sat, Oct 29, 2022 at 22:09 Nick Nugent  wrote:
>
>> Thanks, Anita. Perhaps it would help to hear more about experimental
>> activities like yours.
>>
>> What would - and this is a question addressed to the broader PPML - an
>> exemplary experimental activity under Section 11 look like? Are there any
>> real-world past examples that ARIN could share?
>>
>> Nick Nugent
>>
>> On Sat, Oct 29, 2022 at 10:13 AM A N  wrote:
>>
>>> Nick -
>>> That's a great catch. "technically sound within the meaning of ARIN’s
>>> Policy Development Process" is hard to decipher. I think the sentence
>>> should end after "technically sound". However "technically sound" is
>>> different from "technically coordinated" and I believe they should both be
>>> in there as requirements. Technically sound is a lightweight way to ensure
>>> that an experiment (or set of experiments) needs a resource space and that
>>> there is a reasoning behind the construction of the experiment.
>>> Coordination ensures that if goes awry, the experimenter has thought of how
>>> to mitigate damage.
>>>
>>> (I'm part of a group that runs a very large network testbed, and our
>>> general process is similar: justify what you're doing, and tell us how
>>> you'll mitigate effects on others.)
>>>
>>> Anita Nikolich
>>> (wearing non AC hat)
>>>
>>>
>>>
>>> On Thu, Oct 27, 2022 at 8:23 PM Nugent, Nick via ARIN-PPML <
>>> arin-ppml@arin.net> wrote:
>>>
 Thanks, Andrew.



 Question: Do we need the following eligibility criterion?



 * Demonstration to ARIN that the experimental activity is technically
 sound within the meaning of ARIN’s Policy Development Process;



 A few thoughts on it:



 (1) It represents a new requirement (it’s not currently in Section 11)



 (2) I’m not sure it makes sense to define “technically sound” by
 reference to the Policy Development Process. Section 4.2 of the PDP defines
 “technically sound” in a very narrow fashion that’s highly specific to
 public number administration—namely:



 - Support both conservation and efficient utilization of Internet
 number resources to the extent feasible. Policy should maximize number
 resource availability to parties with operational need.



 - Support the aggregation of Internet number resources in a
 hierarchical manner to the extent feasible. Policy should permit the
 routing scalability that is necessary for continued Internet growth. (Note
 that neither ARIN, nor its policies, can guarantee routability of any
 particular Internet number resource as that is dependent on the actions of
 the individual Internet operators.)



 - Support the unique registration of Internet number resources. Policy
 should prevent to the extent feasible any unknown or duplicate use of
 Internet number resources that could disrupt Internet communications.



 Presumably, these criteria would be irrelevant to many experimental
 activities. And in any event, these criteria seem more fitting for how ARIN
 administers public numbers than for how a private experiment is conducted.



 (3) To the extent “technically sound” means that the experimental
 activity wouldn’t harm the operation of the internet, that requirement is
 already covered by the following criterion:



 * Demonstration to ARIN that the experimental activity is technically
 coordinated in that consideration of any potential negative impact of the
 proposed experiment on the operation of the Internet and its deployed
 services has been considered, and a description of experimenter mitigation
 plans to contain any negative impacts has been provided.



 Or am I thinking of experimental activities too broadly (or narrowly)?



 Thanks,

 *Nick Nugent* | *Amazon.com*
 Senior Corporate Counsel, Amazon Web Services
 Email: nic...@amazon.com



 *From:* ARIN-PPML  *On Behalf Of *Andrew
 Dul
 *Sent:* Thursday, October 27, 2022 8:07 AM
 *To:* arin-ppml@arin.net
 *Subject:* RE: [EXTERNAL][arin-ppml] Revised - Draft Policy
 ARIN-2022-8: Streamlining Section 11 Policy Language



 *CAUTION*: This email originated from outside of the organization. Do
 not click links or 

Re: [arin-ppml] Revised - Draft Policy ARIN-2022-8: Streamlining Section 11 Policy Language

[David Farmer via ARIN-PPML]

Here is an example of an experimental allocation made by ARIN;

https://labs.ripe.net/author/emileaben/propagation-of-longer-than-24-ipv4-prefixes/

It is probably not a typical instance of such an allocation, but I’m not
sure there is such a thing.

Thanks

On Sat, Oct 29, 2022 at 22:09 Nick Nugent  wrote:

> Thanks, Anita. Perhaps it would help to hear more about experimental
> activities like yours.
>
> What would - and this is a question addressed to the broader PPML - an
> exemplary experimental activity under Section 11 look like? Are there any
> real-world past examples that ARIN could share?
>
> Nick Nugent
>
> On Sat, Oct 29, 2022 at 10:13 AM A N  wrote:
>
>> Nick -
>> That's a great catch. "technically sound within the meaning of ARIN’s
>> Policy Development Process" is hard to decipher. I think the sentence
>> should end after "technically sound". However "technically sound" is
>> different from "technically coordinated" and I believe they should both be
>> in there as requirements. Technically sound is a lightweight way to ensure
>> that an experiment (or set of experiments) needs a resource space and that
>> there is a reasoning behind the construction of the experiment.
>> Coordination ensures that if goes awry, the experimenter has thought of how
>> to mitigate damage.
>>
>> (I'm part of a group that runs a very large network testbed, and our
>> general process is similar: justify what you're doing, and tell us how
>> you'll mitigate effects on others.)
>>
>> Anita Nikolich
>> (wearing non AC hat)
>>
>>
>>
>> On Thu, Oct 27, 2022 at 8:23 PM Nugent, Nick via ARIN-PPML <
>> arin-ppml@arin.net> wrote:
>>
>>> Thanks, Andrew.
>>>
>>>
>>>
>>> Question: Do we need the following eligibility criterion?
>>>
>>>
>>>
>>> * Demonstration to ARIN that the experimental activity is technically
>>> sound within the meaning of ARIN’s Policy Development Process;
>>>
>>>
>>>
>>> A few thoughts on it:
>>>
>>>
>>>
>>> (1) It represents a new requirement (it’s not currently in Section 11)
>>>
>>>
>>>
>>> (2) I’m not sure it makes sense to define “technically sound” by
>>> reference to the Policy Development Process. Section 4.2 of the PDP defines
>>> “technically sound” in a very narrow fashion that’s highly specific to
>>> public number administration—namely:
>>>
>>>
>>>
>>> - Support both conservation and efficient utilization of Internet number
>>> resources to the extent feasible. Policy should maximize number resource
>>> availability to parties with operational need.
>>>
>>>
>>>
>>> - Support the aggregation of Internet number resources in a hierarchical
>>> manner to the extent feasible. Policy should permit the routing scalability
>>> that is necessary for continued Internet growth. (Note that neither ARIN,
>>> nor its policies, can guarantee routability of any particular Internet
>>> number resource as that is dependent on the actions of the individual
>>> Internet operators.)
>>>
>>>
>>>
>>> - Support the unique registration of Internet number resources. Policy
>>> should prevent to the extent feasible any unknown or duplicate use of
>>> Internet number resources that could disrupt Internet communications.
>>>
>>>
>>>
>>> Presumably, these criteria would be irrelevant to many experimental
>>> activities. And in any event, these criteria seem more fitting for how ARIN
>>> administers public numbers than for how a private experiment is conducted.
>>>
>>>
>>>
>>> (3) To the extent “technically sound” means that the experimental
>>> activity wouldn’t harm the operation of the internet, that requirement is
>>> already covered by the following criterion:
>>>
>>>
>>>
>>> * Demonstration to ARIN that the experimental activity is technically
>>> coordinated in that consideration of any potential negative impact of the
>>> proposed experiment on the operation of the Internet and its deployed
>>> services has been considered, and a description of experimenter mitigation
>>> plans to contain any negative impacts has been provided.
>>>
>>>
>>>
>>> Or am I thinking of experimental activities too broadly (or narrowly)?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> *Nick Nugent* | *Amazon.com*
>>> Senior Corporate Counsel, Amazon Web Services
>>> Email: nic...@amazon.com
>>>
>>>
>>>
>>> *From:* ARIN-PPML  *On Behalf Of *Andrew Dul
>>> *Sent:* Thursday, October 27, 2022 8:07 AM
>>> *To:* arin-ppml@arin.net
>>> *Subject:* RE: [EXTERNAL][arin-ppml] Revised - Draft Policy
>>> ARIN-2022-8: Streamlining Section 11 Policy Language
>>>
>>>
>>>
>>> *CAUTION*: This email originated from outside of the organization. Do
>>> not click links or open attachments unless you can confirm the sender and
>>> know the content is safe.
>>>
>>>
>>>
>>> Updated markup and new version can be found here for your review.
>>>
>>>
>>> https://www.arin.net/participate/policy/drafts/pdf/NRPM-Section11-update-20221021.pdf
>>>
>>> https://www.arin.net/participate/policy/drafts/pdf/NRPM-Section11-update-20221021-clean.pdf
>>>
>>> Thanks,
>>> Andrew
>>>
>>> On 

Re: [arin-ppml] Revised - Draft Policy ARIN-2022-2: Remove Barrier to BGP Uptake in ASN Policy

[David Farmer via ARIN-PPML]

On Sun, Sep 18, 2022 at 10:59 Gary Buhrmaster 
wrote:

> On Sun, Sep 18, 2022 at 8:03 AM William Herrin  wrote:
> >
> > On Tue, Sep 13, 2022 at 7:46 AM ARIN  wrote:
> > > Any organization may be issued a single Autonomous System Number (ASN)
> upon request. Organizations that have space issued under Multiple Discrete
> Networks policy may be issued one ASN per discrete network upon request.
> > >
> > > Additional ASN requests should include proof of the requestor's need
> for a unique routing policy, or other technical justification for the need
> for more than one ASN.
> >
> > I conditionally support this proposal on the condition that there is
> > an accompanying change to the fee schedule such that the second and
> > subsequent AS numbers assigned to a single organization each incur an
> > additional annual fee.
>
> I tend to agree here (although, as always, fees are not
> an issue for policy discussions.)
>
> I would think that all orgs (RSP and ASN only orgs)
> should end up paying the same annual fee per ASN
> (currently $150/yr/ASN), with, perhaps, some number
> of ASN's included without additional fee per service
> category size (1 for a 3x-small customer, 2 for a
> 2x-small, 4 for a x-small, ???).


I support this policy as written.

While fees are out of scope for policy, I’ll note there is still a $550
Transactional Fee for the issuance of an ASN, I think that is a
sufficiently large fee to discourage excessive use of ASNs.

Furthermore, given this policy makes the issuance of the first ASN for an
organization almost pro forma, maybe the board should consider waiving the
transactional for the first ASN issued to an organization. I think the
transactional fee for subsequently issued ASNs, even for Multiple Discrete
Networks, is appropriate.

Thanks.


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2022-13: Clean-up of NRPM Section 2.10

[David Farmer via ARIN-PPML]

Opposed as written.

I agree; the new definition is less clear and way more abstract, in my
opinion.  Further, without a more specific statement of a problem with or a
misunderstanding created by the current text, I would prefer to keep the
current text.

Thanks.

On Tue, Aug 23, 2022 at 12:13 PM Andrew Dul  wrote:

> Opposed as written.
>
> I do not find the new definition to be clearer, I do not know what a
> "non-divisible physical or virtual point" is or isn't
>
> Andrew
>
> On 8/23/2022 9:30 AM, ARIN wrote:
>
> On 18 August 2022, the ARIN Advisory Council (AC) accepted "ARIN-prop-318:
> Clean-up of NRPM Section 2.10" as a Draft Policy.
>
>
>
> Draft Policy ARIN-2022-13 is below and can be found at:
>
>
>
> https://www.arin.net/participate/policy/drafts/2022_13/
>
>
>
> 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,
>
>
>
> Sean Hopkins
>
> Senior Policy Analyst
>
> American Registry for Internet Numbers (ARIN)
>
>
>
>
>
>
>
> Draft Policy ARIN-2022-13: Clean-up of NRPM Section 2.10
>
>
>
> Problem Statement:
>
>
>
> This proposal continues the work that the ARIN AC NRPM Clean-up Working
> Group undertook to conduct an editorial review of the NRPM. It relates
> specifically to Section 2.10. The focus of this proposal is to both clarify
> and simplify the wording of the section.
>
>
>
> Policy statement:
>
>
>
> Replace the existing text: “The term End Site shall mean a single
> structure or service delivery address, or, in the case of a multi-tenant
> structure, a single tenant within said structure (a single customer
> location).” With the new text: “An End Point is the smallest non-divisible
> physical or virtual point in a network requiring IPv6 address space.”
>
>
>
> Timetable for Implementation: Immediate
>
>
>
> Anything Else: This proposal is intended to replace ARIN-prop-305 in part,
> but is not considered strictly editorial in nature.
>
>
>
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription 
> at:https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - ARIN-2021-8: Deprecation of the ‘Autonomous System Originations’ Field

[David Farmer via ARIN-PPML]

On Wed, Aug 17, 2022 at 12:19 PM ARIN  wrote:

Policy Statement:
>
>
>
> Remove Section 3.5 “Autonomous System Originations” of the NRPM in its
> entirety.
>
>
>
> Timetable for Implementation: Two years after ARIN Board adoption.
>

By my read, this changes the timetable for Implementation from "One year
after ARIN Board adoption" to "Two years after ARIN Board adoption."

I agree with this as the timetable for the removal of the OriginAS field
from the database. However, I think the changes to the policy text
should occur immediately. So, how about "Timetable for Implementation:
Revision of policy text immediately and changes to the database occurring
two years after ARIN Board adoption."

If ARIN-2006-3 ,
the policy that created the OriginAS field, had been proposed today, it is
quite possible that it would have been handled by the ARIN Consultation and
Suggestion Process (ACSP)
 instead
of the Policy Process, as it is not entirely clear that it even needs to be
a policy. Therefore, I believe the policy text can be removed from the NRPM
immediately. However, the changes to the database should have much more
lead time, and I think the two years suggested are appropriate.

Thanks.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN actions regarding address blocks with no valid POCs (was: Re: Deceased Companies?)

[David Farmer via ARIN-PPML]

ERX: Early Registration Transfers mostly happened a long time ago or
shortly after LACNIC and AFRINIC were created. See the following;

https://www.arin.net/vault/participate/meetings/reports/ARIN_X/PDF/erx.pdf


On Sat, Aug 6, 2022 at 17:24 Ted Mittelstaedt  wrote:

> Once more, nobody cares about those because they are _in use_.
>
> Interesting that there's a handful of legacy space in other RIRs.  I
> hadn't thought about transfers.  However I don't believe transfers
> can happen unless they sign an LSRA so they are "in the system" at that
> point.
>
> Ted
>
> On 8/6/2022 2:19 PM, Mike Burns wrote:
> > Just a point of clarification.
> > ARIN is not the only RIR with legacy blocks.
> > Check ARIN ERX Transfers.
> > Every RIR has them, and has similar policies regarding them.
> > There are some significant differences related to transfers of legacy
> space.
> >
> > Regards,
> > Mike
> >
> >
> >
> >
> > --- Original Message ---
> > *From :* Ted Mittelstaedt[mailto:t...@ipinc.net]
> > *Sent :* 8/6/2022 4:10:28 PM
> > *To :* l...@dilkie.com; pmcn...@cameron.net
> > *Cc :* arin-ppml@arin.net
> > *Subject :* RE: Re: [arin-ppml] ARIN actions regarding address blocks
> > with no valid POCs (was: Re: Deceased Companies?)
> >
> > Nobody not even me is suggesting that. What I am saying is that the
> > ARIN community has that power.
> >
> > Ted
> >
> > On 8/6/2022 11:25 AM, Lee Dilkie wrote:
> >  > The legacy blocks were created and in existence before ARIN took
> >  > responsibility of them and while ARIN could simply take them all back,
> >  > with no regard for history, it smacks of "colonialism" to me. You
> know,
> >  > where the enlightened civilized folks take property from the savages
> >  > because they can put it to better use. Those savages aren't even
> paying
> >  > tax (arin fees) so really they should have no rights at all.
> >  >
> >  > See? That's how history repeats itself.
> >  >
> >  > -lee
> >  >
> >  > On 2022-08-06 11:45, Ted Mittelstaedt wrote:
> >  >> That is correct which is why John has repeatedly stated that action
> on
> >  >> these needs to originate with the community.  Essentially the RIR
> >  >> system's legal support and basis for power is the same as the United
> >  >> Nations various subcommittees such as WIPO - general consensus among
> >  >> members.
> >  >>
> >  >> ARIN is the only RIR that has legacy blocks so this is a unique issue
> >  >> with just the ARIN RIR.  Most of the rest of ARIN such as NRPM is
> used
> >  >> as a pattern by the other RIRs.
> >  >>
> >  >> It is likely that what the community does with regards to the legacy
> >  >> blocks will have an effect on the "deceased company" issue but the
> >  >> simple reality with registered blocks, which John has tried to get
> >  >> people to understand, is that as long as an entity is paying the
> >  >> renewal fees, while it might be apparent that the block is "on
> >  >> autopilot" and is not in use/being sat on/etc. and that is incredibly
> >  >> irritating, the existence of ongoing payments and ongoing claims that
> >  >> the block is "in use" by the payor and the existence of the original
> >  >> contract between the entity and the RIR, all of that establishes a
> >  >> legal right to continue to have the registration, by that entity.
> >  >>
> >  >> If ARIN acts without consensus among the community, then it
> >  >> jeopardizes the entire RIR system.  We don't want the UN coming in
> and
> >  >> taking it all over and the UN doesn't want to do that as long as the
> >  >> RIR system appears to be functioning on consensus.
> >  >>
> >  >> The gray line is what constitutes legitimate operations of the RIR
> and
> >  >> where is the line between that and operations that cannot happen
> >  >> without consensus to modify the NRPM.  I have argued in the past that
> >  >> ARIN has enough authority by the NRPM to houseclean - John's
> statement
> >  >> a few days ago contradicts that - which means as John said if we want
> >  >> ARIN to take a broom to the legacy blocks, we have to give them more
> >  >> authority to do so by modifying the NRPM.
> >  >>
> >  >> The actual truth is that if the community was united it could revoke
> >  >> all legacy blocks tomorrow despite whatever legalities people out
> >  >> there would argue.  Ultimately it all comes down to what the major
> ISP
> >  >> networks would accept, just because a RIR says a block is assigned to
> >  >> someone else doesn't mean all the major ISPs are required to adhere
> to
> >  >> that.  In practice the major ISPs do because they prefer this over
> the
> >  >> chaos that would result otherwise, but ultimately all a legacy block
> >  >> is, is a checkoff in a database in ARIN.  Nobody HAS to actually
> >  >> follow it.
> >  >>
> >  >> We could vote in power to ARIN to revoke and they could do it.  It
> >  >> would be a hellofa mess and absolutely the wrong thing to do - but
> the
> >  >> community absolutely does have the power to do it.
> >  >>
> >  

Re: [arin-ppml] IPv6 Allocations

[David Farmer via ARIN-PPML]

Thank you for the clarification. And I eagerly await the policy proposal
changing that language.

I meant to ask this at the Open Mic session this morning, but I had someone
at my door and by the time I got back, the meeting was all over.

WOW, that was quick!

I hope everyone has a safe trip home.

Later.

On Wed, Apr 27, 2022 at 10:17 AM John Sweeting  wrote:

> David,
>
> While every issued resource is allocated the size of IPv6 is determined by
> the policy they are requested under as either end user or ISP. So an ISP
> requesting IPv6 is still evaluated under NRPM 6.5.2 and an end user is
> evaluated under NRPM 6.5.8. It is my understanding that the ARIN AC is
> currently reviewing section 6 in its entirety. The change from
> “assignments” to “allocations” for end users does not change the criteria
> they are evaluated under.
>
> Sent from my iPhone
>
> On Apr 27, 2022, at 9:46 AM, David Farmer via ARIN-PPML <
> arin-ppml@arin.net> wrote:
>
> 
> In I believe the IANA resource report at ARIN 49, John Sweeting mentioned
> that ARIN is now only making allocations. Since the smallest IPv6
> allocation in policy is a /40, does that mean that ARIN is no longer
> handing out /48s or /44s to organizations that formerly would have
> received end-users assignments of those sizes?
>
> Thanks
> --
> ===
> David Farmer   Email:far...@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
>

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

[arin-ppml] IPv6 Allocations

[David Farmer via ARIN-PPML]

In I believe the IANA resource report at ARIN 49, John Sweeting mentioned
that ARIN is now only making allocations. Since the smallest IPv6
allocation in policy is a /40, does that mean that ARIN is no longer
handing out /48s or /44s to organizations that formerly would have
received end-users assignments of those sizes?

Thanks
--
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2021-8: Deprecation of the 'Autonomous System Originations' Field

[David Farmer via ARIN-PPML]

I'd be fine with eliminating section 3.5 of the NRPM now, and a deprecation
timeline for the Origin AS field in the 2-5 year timeframe that Andrew is
suggesting.  Furthermore, I'm fine with ARIN leveraging the new IRR and
RPKI to get legacy holders to sign the LRSA. But if we want to do that ARIN
shouldn't deprecate Origin AS, in the short term, that is less than a 2-5
year timeframe. Otherwise, if the priority is seen as deprecating the
Origin AS field, in the short term, then legacy holders should be
allowed access to the new IRR.

Thanks

On Tue, Apr 26, 2022 at 5:19 PM Andrew Dul  wrote:

> Legacy holders have the option to add records to ARIN’s authenticated irr.
> It only requires them to sign an lrsa or rsa. In my opinion it is time for
> the free ride for legacy holders to end.
>
> I have no problem with a sunset date say 2-5 years from now but we need to
> move in that direction.
>
> Speaking only for myself and not for any organization or in any position.
>
> Andrew
>
>
> > On Apr 26, 2022, at 14:39, Scott Leibrand 
> wrote:
> >
> > IMO there is a need for number resource holders to be able to attest
> (solely) that a given origin ASN is (solely) authorized to announce
> route(s) for those number resources.
> >
> > Most forms of RPKI, like DNSSEC, are really easy to screw up in such a
> way that you knock your own services off the Internet. As long as that
> remains true, it will likely never get to 100% adoption. If it does, it
> will be because it allows number resource holders to make attestations via
> the RIRs as to who is authorized to announce their route(s), without
> requiring the resource holders to sign their route announcements in such a
> way that screwing up key rotation will cause them to be rejected.
> >
> > Fully authenticated IRR solutions can provide all the same services that
> putting an origin ASN into whois provides, but only for non-legacy
> resources. Until ARIN is willing to provide basic authenticated IRR
> services to legacy resource holders, it seems we still need the origin ASN
> field as long as it continues to be used.
> >
> > Scott
> >
> >> On Apr 26, 2022, at 9:07 PM, James Hulce via ARIN-PPML <
> arin-ppml@arin.net> wrote:
> >>
> >> snipped, with inline comments
> >>> On Tue, Apr 26, 2022 at 1:07 PM Job Snijders via ARIN-PPML
> >>>  wrote:
> >>> I'm the one who initiated the process towards ARIN-2021-8. I've put in
> >>> considerable effort to find a purpose and use for the ARIN Originations
> >>> field in automated tool chains, and ultimately concluded the field has
> >>> so many apparent challenges it might be better to get rid of it,
> >>> especially since IRR and RPKI nowadays exist.
> >> Job, thanks for coming here to explain your perspective. I, for one,
> >> was surprised to see your name attached to the original policy
> >> proposal given all of your past work in this space.
> >>
> >>>>> On Tue, Apr 26, 2022 at 11:53:58AM -0500, David Farmer via ARIN-PPML
> wrote:
> >>>>> While I do not support the deprecation of the 'Autonomous System
> >>>>> Originations' Field from the database at this time for many of the
> reasons
> >>>>> discussed at the microphone at ARIN 49.
> >>>
> >>> Unfortunatey, I wasn't there. Would you be so kind to outline the many
> >>> reasons in an email?
> >> My comment: Oppose this proposal at this time. The Autonomous System
> >> Origination field in ARIN Whois occupies a peculiar yet potentially
> >> valuable place in the routing information landscape. It provides an
> >> easy and authenticated way for everyone, including legacy resource
> >> holders, to communicate their routing intentions. OriginAS does not
> >> suffer from other problems associated with IRR, such as proxy records
> >> or multiple disparate databases. Several organizations, networks, and
> >> exchanges report using the OriginAS field to generate filters and
> >> perform other operational tasks despite consumption issues. Without
> >> much known about its uptake, usage, accuracy, and role, deprecation
> >> would be premature.  (generally summarized my PPML post from last
> >> week)
> >>
> >> Attempting to outline what others said:
> >> There was general agreement around the point that ARIN Whois OriginAS
> >> is a unique, weird legacy thing and should go away eventually. There
> >> is a desire to eventually reach RPKI's promised land and retire all of
> >> the earlier outmoded and problematic rout

Re: [arin-ppml] Draft Policy ARIN-2021-8: Deprecation of the 'Autonomous System Originations' Field

[David Farmer via ARIN-PPML]

While I do not support the deprecation of the 'Autonomous System
Originations' Field from the database at this time for many of the reasons
discussed at the microphone at ARIN 49. Nevertheless, as discussed in the
problem statement this field has several problems and it eventually needs
to be deprecated. However, since this is an optional field within the ARIN
database, without any enforcement actions required by policy, it seems
possible to remove section 3.5 from the NRPM at this time, without also
deprecating the field at this time.

Further, this would set things up for the future deprecation of the
'Autonomous System Originations' Field from the database to proceed when
the community feels that is appropriate, as expressed through a separate
ARIN Consultation Process, without necessitating additional policy actions.

If this policy proposal were modified to only remove section 3.5 from the
NRPM at this time, with the deprecation of the 'Autonomous System
Originations' Field from the database occurring at some future date, to be
determined at a later time by the ARIN community, I would support this
policy proposal proceeding forward.

Thank you.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised and Retitled - Draft Policy ARIN-2021-6: Permit IPv4 Leased Addresses for Purposes of Determining Utilization for Future Allocations

[David Farmer via ARIN-PPML]

Yes, bundling IPv4 addresses with bandwidth is permitted, and in the past
was common practice, heck even the expected practice. However, the fact
that IPv4 address demand isn't decreasing significantly, the costs to
acquire new IPv4 addresses are increasing significantly, and with the
increasing commoditization of bandwidth, it is no longer economically
viable to bundle bandwidth, and its associated connectivity, with IPv4
addressing. This is driving a structural separation of bandwidth,
connectivity, and IPv4 addressing, from each other, instead of bundling
them together as in the past.

Let me state that differently; ISPs are being driven, buy cost
conscience consumers, to separate the costs of bandwidth and the costs of
the IPv4 addresses needed to utilize the bandwidth from each other.
Minimally this separation is achieved by accounting for the costs on
separate line items of a common bill from a single provider. However, price
competition for bandwidth and IPv4 addresses separately will inevitably
drive a structural separation between the two. Consumers will want the best
price they can get for bandwidth and the best price they can get for IPv4
addresses, regardless of whether they come from a single provider or not.

Some may argue this is being driven by the existence of address brokers,
and their desire to make money, I disagree. While address brokers making
money is the grease that keeps this machine working, the need for the
machine is driven by; IPv4 free pool exhaustion, the increasing cost of
IPv4 addresses, and the lack of adoption of IPv6.
In other words, address brokers wouldn't exist if there wasn't a demand for
their services.

In short, the economic conditions that allowed for and even encouraged the
bundling of IPv4 addresses with bandwidth and connectivity no longer
exist, that world is gone. While I have not personally yet determined if I
support this particular policy text, nevertheless, the time has come to
recognize the next step in this inextricable evolution of IPv4 address
policy by the ARIN policy community and permit IPv4 leasing.

Thanks.

On Fri, Mar 11, 2022 at 5:05 PM John Santos  wrote:

> I disagree.  The addresses are useless unless they ALSO purchase access
> and
> routing from another network operator.  How is this cheaper?
>
> It is and always has been allowed to lease bundled access of addresses and
> connectivity from a LIR, without any expense for purchasing those
> addresses.
>
>
> On 3/11/2022 12:13 PM, Tom Fantacone wrote:
> > I support the proposal as written.
> >
> > It facilitates the provision of a valuable service to a large swath of
> the ARIN
> > community, namely the ability of network operators with an operational
> need to
> > lease IPv4 addresses from 3rd party lessors at a fraction of the cost of
> > purchasing those addresses.  Too often we have seen network operators
> justify
> > their need for IPv4 space only to find that they can't afford to make
> the
> > purchase.  They end up using CGNAT or some other sub-optimal solution.
> >
> > Bill, regarding your point "B", by providing IPv4 leasing, these 3rd
> parties are
> > certainly performing a function that ARIN does not.
> >
> >
> >
> >  On Thu, 10 Mar 2022 17:46:36 -0500 *William Herrin *
> wrote 
> >
> > On Wed, Mar 9, 2022 at 8:24 PM ARIN  i...@arin.net>>
> > wrote:
> >  > * ARIN-2021-6: Permit IPv4 Leased Addresses for Purposes of
> Determining
> > Utilization for Future Allocations
> >
> > I continue to OPPOSE this proposal because:
> >
> > A) It asks ARIN to facilitate blatant and unapologetic rent-seeking
> > behavior with changes to public policy.
> >
> > B) It proposes that third parties perform precisely and only the
> > functions that ARIN itself performs without any credible compliance
> > mechanism to assure the third party performs to ARIN's standards or
> in
> > accordance with the community's established number policy.
> >
> > Regards,
> > Bill Herrin
> >
> >
> > --
> > William Herrin
> > b...@herrin.us 
> > https://bill.herrin.us/ 
> > ___
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net
> > ).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > 
> > Please contact i...@arin.net  if you
> experience any
> > issues.
> >
> >
> >
> >
> > ___
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > 

[arin-ppml] FCC: Notice of Inquiry into Internet Routing Vulnerabilities;

[David Farmer via ARIN-PPML]

Today the FCC put out a Notice of Inquiry into Internet Routing
Vulnerabilities;
https://docs.fcc.gov/public/attachments/FCC-22-18A1.pdf

While not directly related to ARIN Policy, given ARIN's role in RPKI
for the US and the entire ARIN Region, I think it is of great interest to
the ARIN community.

Thanks

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2021-4: Clarifications to Sections 8.3, 8.4 and 8.5.6

[David Farmer via ARIN-PPML]

On Fri, Jan 21, 2022 at 11:18 AM Scott Leibrand 
wrote:

> Are Inter-regional transfers of ASNs allowed via policy today?
>

My understanding is, YES they are; See ARIN-2018-1

https://www.arin.net/vault/policy/proposals/2018_1.html

Thanks

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2021-4: Clarifications to Sections 8.3, 8.4 and 8.5.6

[David Farmer via ARIN-PPML]

The problem I have with that is it strongly implies IPv6 isn’t ever
transferable, even though it is through section 8.2.

A few thoughts;

1. Adding that resource types are considered “separately and
independently”, should eliminate the need to use the awkward “and/or”
construction, and we should be able to simply use “IPv4 addresses or ASNs”
without confusion following that statement. I’d prefer to do this is
section 8.1 instead of section 2. So it isn’t disconnected from section 8
where it is important to understand.

2. Rather than defining “transferable resources” in section 2, how about
saying “only IPv4 addresses or ASNs are transferable, except where
explicitly noted otherwise,” again in section 8.1, for similar reason as
above. Then add “including IPv6” in the heading to section 8.2, making it
clear that IPv6 is included for section 8.2 transfers, and only section 8.2.

3. In sections 8.3 and 8.4, either just simply say “number resources”, with
the above clearly scoping that to IPv4 addresses or ASNs. Or, say “ IPv4
addresses or ASNs”, without the awkward “and/or” construction. I prefer
using just “number resources”, as I think it is simpler and cleaner.

4. Where a clause only applies to “IPv4 addresses”, such as for block
sizing, and the wait list, make sure they are explicitly scoped to IPv4.

Thanks.

On Thu, Oct 21, 2021 at 21:06 Chris Woodfield  wrote:

> I think Joe’s got a good suggestion that I would support - define
> “transferable number resources” as IPv4 addresses and ASNs in Section 2,
> and go from there.
>
> -C
>
> On Oct 21, 2021, at 5:39 PM, Martin Hannigan  wrote:
>
>
>
> On Thu, Oct 21, 2021 at 14:53 Chris Woodfield  wrote:
>
>> I support this edit, for same reasons others have mentioned.
>>
>> If I’m recalling yesterday’s presentation correctly, it was ARIN Staff
>> and Legal, not the AC, that determined that this language could not be
>> implemented an editorial change, so that’s not up for debate here.
>>
>> One possible adjustment that I’d like to suggest is that the term “IPv4
>> and/or ASN resources” seems a bit awkward, given how many times it appears
>> in the section. Perhaps we could add a new section that incorporates
>> David’s suggested language, but also handles the clarification of the
>> definition of number resources in a single place, scoped to Section 8.
>>
>> So, a new Section 8.1.1, which I’d propose would be named “Definitions”,
>> could read as follows:
>>
>>
>> All references to “number resources" in this section, unless stated
>> otherwise, refer to IPv4 addresses and/or ASN resources.
>>
>> When number resources of multiple types, including IPv6 resources, are
>> transferred, each resource type is considered separately and independently,
>> both for any conditions on their transferability and the application of any
>> restrictions following a transfer.
>>
>>
>> Following this, the other edits to Section 8 in the proposal can simply
>> be changed to “number resources” to suit.
>>
>> Opinions?
>>
>> -C
>>
>
> We’d be better off using defined terms. Easier to construct, but end up
> being document global.
>
> Warm regards,
>
> -M<
>
>
>
>
>>
>> On Oct 21, 2021, at 11:23 AM, Martin Hannigan  wrote:
>>
>>
>> I agree with Owen re: the editorial nature of the changes. However, I
>> support it moving forward. I don't support the Farmer suggestion. That is
>> possibly a material change that should undergo the rigors of "the process"
>> on its own.
>>
>> Warm regards,
>>
>> -M<
>>
>>
>>
>>
>>
>> On Thu, Oct 21, 2021 at 11:33 AM Owen DeLong via ARIN-PPML <
>> arin-ppml@arin.net> wrote:
>>
>>> I support this amendment.
>>>
>>> Owen
>>>
>>>
>>> On Oct 20, 2021, at 12:45 , David Farmer via ARIN-PPML <
>>> arin-ppml@arin.net> wrote:
>>>
>>> I support this proposal as currently written.
>>>
>>> However, regarding Kevin Blumberg's comment at the ARIN 48 discussion of
>>> this policy earlier today; How about adding a paragraph like the following
>>> to section 8.1, Principles;
>>>
>>> When number resources of multiple types, IPv4, IPv6, and/or ASNs, are
>>> transferred, each resource type is considered separately and independently,
>>> both for any conditions on their transferability and the application of any
>>> restrictions following a transfer.
>>>
>>>
>>> Something like this added to Section 8.1, Principles, along with the
>>> already proposed changes should elim

Re: [arin-ppml] Draft Policy ARIN-2021-4: Clarifications to Sections 8.3, 8.4 and 8.5.6

[David Farmer via ARIN-PPML]

I support this proposal as currently written.

However, regarding Kevin Blumberg's comment at the ARIN 48 discussion of
this policy earlier today; How about adding a paragraph like the following
to section 8.1, Principles;

When number resources of multiple types, IPv4, IPv6, and/or ASNs, are
transferred, each resource type is considered separately and independently,
both for any conditions on their transferability and the application of any
restrictions following a transfer.


Something like this added to Section 8.1, Principles, along with the
already proposed changes should eliminate any possibility of confusion in
this regard.

Thanks

On Tue, Aug 24, 2021 at 7:52 AM ARIN  wrote:

> On 19 August 2021, the ARIN Advisory Council (AC) accepted "ARIN-prop-299:
> Clarifications to Sections 8.3, 8.4 and 8.5.6" as a Draft Policy.
>
>
>
> Draft Policy ARIN-2021-4 is below and can be found at:
>
>
>
> https://www.arin.net/participate/policy/drafts/2021_4/
>
>
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion in order 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,
>
>
>
> Sean Hopkins
>
> Senior Policy Analyst
>
> American Registry for Internet Numbers (ARIN)
>
>
>
>
>
>
>
>
>
> Draft Policy ARIN-2021-4: Clarifications to Sections 8.3, 8.4 and 8.5.6
>
>
>
> Problem Statement:
>
>
>
> The current language in Sections 8.3 and 8.4 is not clear regarding
> ASN-only transactions as well as the term “number resources”. The current
> language in Section 8.5.7 is not clear with regard to additional IPv4 space.
>
>
>
> Policy statement:
>
>
>
> In Section 8.3:
>
>
>
> Replace
>
>
>
> “In addition to transfers under section 8.2, IPv4 numbers resources and
> ASNs may be transferred according to the following conditions.”
>
>
>
> with
>
>
>
> “In addition to transfers under section 8.2, IPv4 address and/or ASN
> resources may be transferred according to the following conditions.”
>
>
>
> Replace
>
>
>
> “The source entity must be the current registered holder of the IPv4
> address resources, and not be involved in any dispute as to the status of
> those resources.”
>
>
>
> with
>
>
>
> “The source entity must be the current registered holder of the IPv4
> address and/or ASN resources, and not be involved in any dispute as to the
> status of those resources.”
>
>
>
> In Section 8.4:
>
>
>
> Replace
>
>
>
> “Inter-regional transfers of IPv4 number resources and ASNs may take place
> only via RIRs who agree to the transfer and share reciprocal, compatible
> needs-based policies.”
>
>
>
> with
>
>
>
> “Inter-regional transfers of IPv4 addresses and/or ASN resources may take
> place only via RIRs who agree to the transfer and share reciprocal,
> compatible needs-based policies.”
>
>
>
> Replace
>
>
>
> “The source entity must be the current rights holder of the IPv4 address
> resources recognized by the RIR responsible for the resources, and not be
> involved in any dispute as to the status of those resources.”
>
>
>
> with
>
>
>
> “The source entity must be the current rights holder of the IPv4 address
> and/or ASN resources recognized by the RIR responsible for the resources,
> and not be involved in any dispute as to the status of those resources.”
>
>
>
> In Section 8.5.6:
>
>
>
> Replace
>
>
>
> “Organizations with direct assignments or allocations from ARIN must have
> efficiently utilized at least 50% of their cumulative IPv4 address blocks
> in order to receive additional space. This includes all space reassigned to
> their customers.”
>
>
>
> with
>
>
>
> “Organizations with direct assignments or allocations from ARIN must have
> efficiently utilized at least 50% of their cumulative IPv4 address blocks
> in order to receive additional IPv4 space. This includes all IPv4 space
> reassigned to their customers.”
>
>
>
> Comments:
>
>
>
> These changes were originally included in ARIN-edit-2021-1. Staff and
> Legal review of ARIN-edit-2021-1 on June 14, 2021 indicated that some
> changes were not editorial in nature. The editorial changes went forward in
> ARIN-edit-2021-1 and the non-editorial changes are included here.
>
>
>
> Timetable for implementation: Immediate
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact 

Re: [arin-ppml] Draft Policy ARIN-2021-6: Remove Circuit Requirement

[David Farmer via ARIN-PPML]

On Thu, Sep 23, 2021 at 17:53 William Herrin  wrote:

> On Thu, Sep 23, 2021 at 2:41 PM David Farmer via ARIN-PPML
>  wrote:
> > I have a question for those that oppose the leasing or loaning of IPv4
> addresses to other entities absent connectivity; Is it the rent-paying or
> that lack of connectivity provided with the addresses that offend you? Or,
> both?
>
> Hi David,
>
> The defined Economics term is "rent seeking." Just renting something
> to someone is not "rent seeking." The term has a specific meaning.
> Briefly, it means exploiting a rule-making process (such as law,
> regulation or other public policy) often by changing it to let you
> make money without adding value.


So, I intentionally didn’t, use that term, but I figured someone would. I
didn’t want to limit my question to that precise meaning, but I didn’t want
to exclude it either.

I have heard it said by some that charging for addresses is wrong, they
should be included with the connectivity for no additional charge. Along
time ago, I felt much the same, but things have changed and that is no
longer realistic. Things have evolved, maybe not for the better, but
nevertheless they have evolved.

Address transfers are at least notionally not rent seeking - the
> recipient isn't paying for the addresses, he's paying the former
> registrant's one-time cost to reconfigure to stop using them while the
> addresses themselves convey to the new registrant for exactly the same
> cost as the original registrant. Yes I know that's ridiculous. Call it
> a "legal fiction."
>
> Address leasing, on the other hand, is unapologetically rent seeking.
> I have them only because the regulatory agency allowed it. I add no
> value by letting you pay me to use them but you have no choice because
> the regulatory agency has no more to offer. I and my contemporaries
> took them all.


Requiring Technical Need doesn’t automatically prevent Rent Seeking, since
most LIRs got most of there addresses from the free pool for minimal cost,
at least no where near the current transfer market cost. It seems to me
that LIRs that are withdrawing there assignments to customers in order to
lease them to other customers are also “unapologetically rent seeking” as
well, and possibly even more so. So, Technical Need is no protection from
Rent Seeking.

What's wrong with a little rent seeking? Rent seeking is
> anticompetitive behavior. Quoting from
> https://www.investopedia.com/terms/r/rentseeking.asp :
>
> "Rent seeking can disrupt market efficiencies and create pricing
> disadvantages for market participants. It has been known to cause
> limited competition and high barriers to entry.
>
> Those that benefit from successful rent seeking obtain added economic
> rents without any added obligations. This can potentially create
> unfair advantages, specifically providing wealth to certain businesses
> that leads to greater market share at the detriment of competitors."


Yes, I agree, but protecting lessors that already have addresses to from
potential competitive lessors, by requiring Technical Need will not prevent
Rent Seeking, and could actually reinforce Rent Seeking by those that have
addresses rather than discouraging such Rent Seeking.

I have no problem with a healthy skepticism of address brokers, they are
out to make money, but there is nothing wrong with that. Furthermore, it’s
not like the MegaCarrier and MegaCable companies are not equally out to
make even more money and some of them are duopolies or even monopolies in
there service territories, talk about Rent Seeking behavior.

So, maybe you could go back to my original question and comment on the
examples I provided.

Thanks.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2021-6: Remove Circuit Requirement

[David Farmer via ARIN-PPML]

First, I do not support this policy as written. However, I do support
allowing leasing or loaning of IPv4 address space independent of providing
connectivity, and probably allowing leasing or loaning of addresses as
justification for at least the transfer of additional addresses, through
purchase in most cases, and probably not by obtaining addresses from the
waiting list, or the reserved blocks of IPv4. Let me address my objection
to this policy language, fundamentally my objection is that by changing the
definition of an LIR that change applies to both IPv4 and IPv6. I would
rather not make changes impacting IPv6 while enabling the leasing or
loaning of IPv4 addresses, which I think is necessary at this point.

I have a question for those that oppose the leasing or loaning of IPv4
addresses to other entities absent connectivity; Is it the rent-paying or
that lack of connectivity provided with the addresses that offend you? Or,
both?

How about an end-user that wants to loan a business partner, another
end-user let's say, IPv4 address in order to ensure they can do business
with that business partner over the Internet? Would this offend you? It is
easy to see how this might be in the business interests of the end-user
that has extra addresses. However, the end-user may not want to transfer
the addresses to their business partner, as they may want to be able to
provide them to a different business partner in the future. In this
example, there isn't necessarily rent-paying but there is no connectivity
at least directly.

As the per megabit cost of bandwidth continues decreasing, especially in
bulk, and the cost of proving the necessary IPv4 addresses to use the
bandwidth is increasing, many providers are being forced to charge their
customers separately for IPv4 addresses in order to be competitive in the
bandwidth marketplace. They, therefore, are being forced to charge their
customers' rent on the IPv4 addresses the customers need, it is frequently
no longer viable to include IPv4 address costs in the bandwidth costs as
has been done in the past. For example, we heard in a different thread
about a WISP that used to have a /20 from their upstream provider and that
provider took back the addresses, presumably to use the addresses in a more
profitable manner. And, the WISP is having a hard time finding replacement
addresses, this unfortunately is a common story. In this example, there is
rent-paying, and connectivity is provided.

For the the other permutations, rent-paying without connectivity has been
discussed extensively so far, and as mentioned above connectivity without
rent-paying has serious economic forces going against that option.

Some of you may counter that we should have never allowed the sale and
monetization of IPv4 resources through transfers in the first place and
suggest we should have had large-scale forced revocation, well I think the
situation with Afrinic and CI is the perfect counterexample to the
feasibility of that as an option.

Thanks



-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] {Spam?} Re: Open Letter Regarding 650% Rate-Hike for Legacy Users

[David Farmer via ARIN-PPML]

The "double billing issue," as you refer to it, is financially
immaterial to us. However, we would prefer one invoice with both Orgs IDs
on it or two invoices but at the same time. The two invoices, at separate
times, creates confusion. I get questions like "didn't we pay this already
this year," when the second invoice comes later in the year. However, even
that is mostly just an annoyance, and the accountants grumble about it, but
they have to have something to grumble about. There was some sticker shock,
at the $16,000 we would have to pay without the LRSA annual fee increase
cap. However, in the end, the total fee really isn't an issue, even if we
didn't have the LRSA annual fee increase cap, even at a total of $17,000
for the two Org IDs it is still one of the smaller costs of operating our
network and the rest of our IT Infrastructure.

Oh, FYI, I always assumed the LRSA annual fee increase cap would be
annually compounding, not a fixed rate based on the first year.

Thanks.

On Tue, Sep 21, 2021 at 12:11 PM Owen DeLong  wrote:

> Is your institution OK with the double-billing that results from that, or
> would you prefer to be treated like other organizations and pay MAX(v4,v6)
> instead of SUM(v4,v6)?
>
> Owen
>
>
> On Sep 21, 2021, at 07:49 , David Farmer  wrote:
>
> I don't know what is typical, but it depends on when the ASNs were
> assigned. Our ASNs are all legacy and on LRSA, and all our IPv4 as well.
> Only IPv6 is on RSA.
>
> On Tue, Sep 21, 2021 at 9:04 AM  wrote:
>
>> In the typical LRSA+RSA case, is the ASN number covered by the LRSA or
>> the
>> RSA?  If the RSA only covers V6, why not consider getting V6 from your
>> upstream and dumping the RSA to save money?  I happen to get V6 addresses
>> from both of my V6 upstreams, without additonal cost.  If the ASN is also
>> part of the RSA, in many cases private ASN's can be used for routing with
>> your upstream(s) without the need for an ASN.
>>
>> Personally, I would like to see this policy changed, as I can see it
>> being
>> used as a quite valid excuse to drop IPv6 because of the cost.  ARIN
>> should not be doing things that make operators less likely to use IPv6,
>> and this price change for those LRSA+RSA people clearly is bad.
>>
>> Albert Erdmann
>> Network Administrator
>> Paradise On Line Inc.
>>
>> On Mon, 20 Sep 2021, Owen DeLong via ARIN-PPML wrote:
>>
>> >
>> >
>> >   On Sep 19, 2021, at 14:35 , John Curran  wrote:
>> >
>> > On 19 Sep 2021, at 1:12 PM, Owen DeLong  wrote:
>> >
>> > On Sep 19, 2021, at 06:32 , John Curran 
>> wrote:
>> > I actually haven’t said that – what I said is that your assertion that
>> the costs are linear (i.e. per IP address represented) are not
>> > realistic, nor is the single fee per-registry-object-regardless-of-size
>> approach realistic.
>> >
>> > Our fee schedule scales in a geometric manner, so the smallest resource
>> holders are paying only $250/year and the largest paying hundreds
>> > of thousands per year.   Does it reflect perfect cost allocation?
>> Almost certainly not, since it generallizations the entire ARIN
>> > customer base into a simple set of fee categories.  It may not be
>> perfect but I believe it is as simple, fair and clear as is possible
>> > under the circumstances.
>> >
>> >
>> > You got two out of three. It’s as simple and clear as possible.
>> >
>> >
>> > Thanks – that’s good to hear.
>> >
>> >   It clearly subsidizes LIRs on the backs of end users that are
>> just ever so slightly larger than the very smallest.
>> >
>> >
>> > It is true that the 8022 end-user customers will be paying a larger
>> portion of overall registry expenses (totaling approx. 1/3 of ARIN's total
>> costs),
>> > but “subsidizes” is probably not a correct characterization – as they
>> will be paying $860 per year on average as compared to the $2341 paid
>> annually
>> > on average by the existing ISP customers.
>> >
>> >
>> > So your assertion is that LIRs only constitute 75% of ARIN’s expenses?
>> Unless you can make that claim, it is, indeed, subsidy.
>> >
>> >   Yes, this does mean an increase in annual fee for those end-users
>> organizations who have more IPv4 number resources, but it also means a
>> >   reduction for more than three thousand end-user organizations who
>> have the typical single /24 IPv4 address block.
>> >
>> >
>> > That’s an extremely low cutoff for the end-user organizations worthy of
>> consideration. A /22 can legitimately still be a very small end-user
>> organization
>> > and this latest fee hike, especially in light of double billing for
>> LRSA+RSA end-users in light of the previous restructuring efforts to screw
>> these
>> > particular end users is quite painful.
>> >
>> > Owen
>> >
>> >
>> >___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:

Re: [arin-ppml] {Spam?} Re: Open Letter Regarding 650% Rate-Hike for Legacy Users

[David Farmer via ARIN-PPML]

I don't know what is typical, but it depends on when the ASNs were
assigned. Our ASNs are all legacy and on LRSA, and all our IPv4 as well.
Only IPv6 is on RSA.

On Tue, Sep 21, 2021 at 9:04 AM  wrote:

> In the typical LRSA+RSA case, is the ASN number covered by the LRSA or the
> RSA?  If the RSA only covers V6, why not consider getting V6 from your
> upstream and dumping the RSA to save money?  I happen to get V6 addresses
> from both of my V6 upstreams, without additonal cost.  If the ASN is also
> part of the RSA, in many cases private ASN's can be used for routing with
> your upstream(s) without the need for an ASN.
>
> Personally, I would like to see this policy changed, as I can see it being
> used as a quite valid excuse to drop IPv6 because of the cost.  ARIN
> should not be doing things that make operators less likely to use IPv6,
> and this price change for those LRSA+RSA people clearly is bad.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
> On Mon, 20 Sep 2021, Owen DeLong via ARIN-PPML wrote:
>
> >
> >
> >   On Sep 19, 2021, at 14:35 , John Curran  wrote:
> >
> > On 19 Sep 2021, at 1:12 PM, Owen DeLong  wrote:
> >
> > On Sep 19, 2021, at 06:32 , John Curran 
> wrote:
> > I actually haven’t said that – what I said is that your assertion that
> the costs are linear (i.e. per IP address represented) are not
> > realistic, nor is the single fee per-registry-object-regardless-of-size
> approach realistic.
> >
> > Our fee schedule scales in a geometric manner, so the smallest resource
> holders are paying only $250/year and the largest paying hundreds
> > of thousands per year.   Does it reflect perfect cost allocation?
> Almost certainly not, since it generallizations the entire ARIN
> > customer base into a simple set of fee categories.  It may not be
> perfect but I believe it is as simple, fair and clear as is possible
> > under the circumstances.
> >
> >
> > You got two out of three. It’s as simple and clear as possible.
> >
> >
> > Thanks – that’s good to hear.
> >
> >   It clearly subsidizes LIRs on the backs of end users that are just
> ever so slightly larger than the very smallest.
> >
> >
> > It is true that the 8022 end-user customers will be paying a larger
> portion of overall registry expenses (totaling approx. 1/3 of ARIN's total
> costs),
> > but “subsidizes” is probably not a correct characterization – as they
> will be paying $860 per year on average as compared to the $2341 paid
> annually
> > on average by the existing ISP customers.
> >
> >
> > So your assertion is that LIRs only constitute 75% of ARIN’s expenses?
> Unless you can make that claim, it is, indeed, subsidy.
> >
> >   Yes, this does mean an increase in annual fee for those end-users
> organizations who have more IPv4 number resources, but it also means a
> >   reduction for more than three thousand end-user organizations who
> have the typical single /24 IPv4 address block.
> >
> >
> > That’s an extremely low cutoff for the end-user organizations worthy of
> consideration. A /22 can legitimately still be a very small end-user
> organization
> > and this latest fee hike, especially in light of double billing for
> LRSA+RSA end-users in light of the previous restructuring efforts to screw
> these
> > particular end users is quite painful.
> >
> > Owen
> >
> >
> >___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] {Spam?} Re: Open Letter Regarding 650% Rate-Hike for Legacy Users

[David Farmer via ARIN-PPML]

On Sun, Sep 19, 2021 at 8:13 PM Michel Py via ARIN-PPML 
wrote:

> > John Curran wrote :
> > but it also means a reduction for more than three thousand end-user
> organizations who have the typical single /24 IPv4 address block.
>
> I'd like to see where it is, as $job[0] is an end-user org with a single
> AS and a single /24, and the annual fee for 2022 will be $100 more than for
> 2021 (the /24 went from $150 to $250).
> In the big scheme of things, this is not going to bankrupt us; my company
> did not get a reduction and got an increase instead.
>
> Michel.
>

If said end user also had an ASN and an IPv6 assignment of /48 - /40, their
total would have been $300, it is now $250. which is the typical
situation for many end users with a single /24. Yes there are also end
users that only had an IPv4 /24 or an IPv4 /24 and an ASN or IPv6
assignment. which would result in an increase.

I hope that helps.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] {Spam?} Re: Open Letter Regarding 650% Rate-Hike for Legacy Users

[David Farmer via ARIN-PPML]

On Sat, Sep 18, 2021 at 10:05 PM Owen DeLong via ARIN-PPML <
arin-ppml@arin.net> wrote:

>
>
> > On Sep 18, 2021, at 03:04 , John Curran  wrote:
> > You can assert that ARIN's costs are predominantly the result of “LIRs”
> but that doesn’t reflect reality – many of our services and functions are
> equivalent for an entire address block and only a small set of them are
> related to subdelegation functions.
>
> IRR
> RPKI
> SWIP/RDAP/WHOIS
> RDNS
> Frequency of updates
> Frequency of additional requests/transfers/etc.
>
> are all impacted more by LIRs than by end users.
>

Yes, there is a difference in the impact on these services by LIR vs
end-user, however I believe total size of allocations or assignments are a
much better predictor of the impact on usage levels of those services.

So, currently end-users don't have access to SWIP, so how do you know they
don't have good uses for it? Probably not good enough to pay more, but if
it didn't cost more would they find uses for it? It is pretty easy to
imagine it could be useful for multijurisdictional end-users to SWIP their
offices in different states and countries, and I'm fairly sure there are
other uses as well.

Also, take my WISP or small ISP example, from earlier in the thread, if
there is a pricing differential on whether or not they SWIP or not, then
you create a financial disincentive for them to SWIP the one or two
customers they might have that justify SWIPing.  So then, they either skirt
or break the rules, or even worse, they don't serve those customers because
that would upset their delicate financial model.

On the other hand, there’s also the fact that the LIRs are (generally)
> using their addresses directly for profit (i.e. their business _IS_ (at
> least in part) providing IP addresses to their customers). Essentially,
> they are reselling RIR services.
> End users, OTOH, tend to be using addresses to run their organization,
> many of which are not for profit and some of which are even individuals or
> families. They aren’t reselling registration services for profit.
>

You're making a moral argument here, not a technical one. I'd be fine with
nonprofit/not-for-profit discounts, however, nonprofits can be fairly large
concerns, take ARIN itself as an example. However, personal use get's
pretty fuzzy and is too easily abused, at least in my opinion. Furthermore,
there are plenty of for profit uses that can make a much larger profit per
IP address than selling connectivity or addressing services. Why should
those uses get preferential pricing? They are still using IP addresses to
make money, even brick and mortar companies are making much more of a
profit from Internet sales.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] {Spam?} Re: Open Letter Regarding 650% Rate-Hike for Legacy Users

[David Farmer via ARIN-PPML]

On Fri, Sep 17, 2021 at 8:26 PM Owen DeLong  wrote:

>
>
> On Sep 17, 2021, at 10:57 , David Farmer via ARIN-PPML 
> wrote:
>
> The lines between what is an end-user and what is an ISP are getting very
> blurry these days. Is there really a difference between a data center, a
> university campus network, an enterprise network, and a small ISP each with
> a /20?
>
>
> The use of the term ISP is what makes them blurry… s/ISP/LIR/ and it gets
> a lot simpler.
>
> Are you running an IP registry where you assign and/or allocate addresses
> to external downstream organizations? YES-> LIR… NO-> End User.
>
> Pretty much that simple.
>

It ain’t really that simple, I wish it was.

>
So some small ISPs, especially WISPs, may not actually SWIP any customers,
because they don't assign any customers a /29, they just DHCP
individual addresses to customers, or they may even NAT their customers.
Are they an end-user since they don't SWIP, or an LIR because they are an
ISP and sell connectivity?

Data centers, run similarly, some do SWIPs and some don’t. Why is it fair
the data center that SWIPs gets one rate and the one that doesn’t gets a
lower rate, sometimes an order of magnitude lower? They mostly are in the
same business, and both usually sell connectivity, why different rates?

Why should an enterprise with a few thousand employees get one rate and an
ISP with the same number of customers have a much higher rate? Are there
networks that much different?  Furthermore, an enterprise with a few
thousand employees probably has many times the revenue, than the ISP with
the same numbers of customers.

And, you’ve been advocating for address leasing lately, so LIRs/ISPs, and
maybe data centers, get to monetize their addresses, but enterprises can’t?
The more addresses are monetized the blurrier the lines get.

Further, I’m not sure there ever was that much of a difference in the
burden on ARIN, between ISPs and similar sized end-users.

Personally, my biggest regret is ARIN didn’t give end-users more than a
full years notice to ensure the increases could have been properly put into
budgets, and maybe a multi-year phase-in for the largest increases.

Nevertheless, it really isn’t as simple as you want to make it.

Thanks.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] {Spam?} Re: Open Letter Regarding 650% Rate-Hike for Legacy Users

[David Farmer via ARIN-PPML]

The lines between what is an end-user and what is an ISP are getting very
blurry these days. Is there really a difference between a data center, a
university campus network, an enterprise network, and a small ISP each with
a /20?

No, this isn't revenue neutral for ARIN, but they have been running
deficits the past few years, and need additional revenue anyway.

Reguaring who made up the the fee structure review panel, see slide 3 of
the following;
https://www.arin.net/vault/participate/meetings/reports/ARIN_32/PDF/friday/curran-fee.pdf

As for outreach;

The creation of the fee structure review panel was announced at ARIN 31,
and on at least one mailing list, if not more.
https://lists.arin.net/pipermail/arin-discuss/2013-April/002699.html

The fee structure review was discussed at several ARIN meetings and final
report was discussed extensively online and at least one ARIN Meeting;
https://www.arin.net/vault/participate/meetings/reports/ARIN_34/PDF/friday/curran-fees.pdf


You know the saying, "you can lead a horse to water, but you can make it
drink." Well unfortunately, there is a corollary, "some people don't pay
attention, until they get the bill."

I'm not sure I completely agree with all the decisions, but there has been
a lot of outreach and the series or decisions that lead us here hasn't been
done in secret, as far as I'm concerned it all has been above boards.

Thanks

On Fri, Sep 17, 2021 at 11:32 AM Mark McDonald  wrote:

> John,
>
> I just came across your spreadsheet of fee increases.  It pretty much
> summarizes what I’ve been saying - this isn’t a neutral harmonization of
> fees, it’s a 20% rate hike on roughly 40% of ARIN’s customers that
> disproportionally affects ARIN’s smaller customers, with Large being the
> middle tier in ARIN’s fee schedule, while targeting end users that use a
> fraction of the services of an ISP.  In nearly 20 years we’ve opened 5
> ticket and in all cases, chose to better optimize IP space rather than pull
> from a finite resource (IPv4 address space).  That works out to about
> $1000/ticket - does it really cost ARIN more than $1000 to respond to a
> ticket?
>
> It would be nice to show in that spreadsheet how many IP’s are represented
> in each Category - both RSP and End User.  My assumption, and I could be
> wrong, is that these fees are going towards users who are already paying
> 30-40x more than those utilizing the most resources.  The previously
> proposed $800/object almost seems like a bargain compared to what’s being
> proposed for us.  This isn’t about the money, it’s about the principal of
> what users ARIN is raising fees on.
>
> I’m curious as to who made/makes up ARIN’s Fee Structure Review Panel and
> why wasn’t outreach done back then?  I was sure notified from 3 different
> departments when ARIN blasted out fee increases of 650% so it seems capable
> of better communication.
>
> What should happen is ARIN truly engages it’s customers and if it needs
> 20% more revenue so badly, perhaps look at taking it from the companies
> that have profited most from the services you provide and who already pay a
> tiny fraction of what smaller users do for the resources (IPv4 addresses)
> they consume.
>
> I need to get back to vendor negotiations.  I’m trying to get Verisign to
> reduce our domain renewal rates by 99.61% because we only use their API and
> don’t consume even a tiny fraction of resources of what a retail customer
> does and they only discount our rates by like 8% - crazy right?!  They’re
> pushing back stating that domain names are a limited resource and we’re
> going to make a boat-load of money off of my proposal by buying nearly
> every domain at 3/10ths of 1% of their normal customer but they simply
> don’t understand the volume we’ll be able to bring.  I’ll keep you posted
> on how my negotiations go.
>
> -Mark
>
> On Sep 17, 2021, at 4:36 AM, John Curran  wrote:
>
> On 17 Sep 2021, at 3:52 AM, hostmas...@uneedus.com wrote:
>
>
> Some have suggested the fee should not have a relationship to the number
> of addresses, but I strongly disagree.
>
> For the most part, the more addresses you have, the more SWIP transactions
> and reverse lookups and customer service transactions are going to take
> place, so it is quite proportional.
>
>
> Albert –
>
> This is incorrect – i.e. the assertion that ARIN’s costs are proportional
> to the span of address space represented by registry objects – and it is
> also likely beyond the possibility of physics (as noted below.)
>
> Larger entities almost always have dedicated personal who knowledgable of
> ARIN and our processes – while they may make some additional customer
> services transactions (due to acquiring additional resources or using more
> advanced services), it would be highly unusual for any of them to make
> hundreds of more frequent customer service requests, let alone the
> thousands, or hundreds of thousands, that you suggest and would be
> necessary for ARIN to bear a proportional 

Re: [arin-ppml] Change of Use and ARIN (was: Re: AFRINIC And The Stability Of The Internet Number Registry System)

[David Farmer via ARIN-PPML]

The historic artifacts are already available, there are early series of
RFCs that are essentially published snapshots of the "notebook". The first
series is titled "Assigned Numbers", and up to RFC960 it includes IP
address assignments, as well as many other protocol assignments. Then later
the series "Internet Numbers", up to RFC 1166, splits out the IP address
assignments from the other protocol assignments after RFC960.

These should be useful to help satisfy your number nerdiness, or the need
to perform early Internet number archaeology.

Thanks

On Thu, Sep 16, 2021 at 8:42 PM Martin Hannigan  wrote:

>
> Makes me want to say ‘let’s see the book’. It is an historic artifact that
> should be scanned and posted somewhere for reference.
>
>
> On Wed, Sep 15, 2021 at 8:08 PM Mark Andrews  wrote:
>
>> I got my first 4 blocks (1 class B, and 3 class C blocks (pre-CIDR) in 4
>> different sites in 4 cities in 4 states) of addresses in ’88 (I know the
>> year because my NIC handle was MA88 and I had noted that both where 88, a
>> coincidence but just the same memorable). Even then there where formal
>> procedures. The organisation was noted in whois.  You where expected to
>> keep those records up to date. Yes, I know Jon did allocate some addresses
>> less formally but most of the pre-ARIN allocations where formally recorded.
>>
>> Mark
>>
>> > On 16 Sep 2021, at 03:59, Martin Hannigan  wrote:
>> >
>> >
>> > Hi Paul,
>> >
>> > It was interesting reading about your problem, your take on matters,
>> the experience and history with ARIN. Thank you for that.
>> >
>> > While I can appreciate ARIN's position from the perspective of 'how do
>> they know', I can appreciate yours too. We're not talking about criminal
>> courts and beyond reasonable doubts. Jon Postel's pre RIR legacy
>> assignments are hand written in a notebook. If that's good enough
>> documentation to establish legacy assignment then providing "reasonable"
>> proof that an address was provided for legitimate use would make a lot of
>> sense to me. However, and admittedly, it's not that simple. Mostly because
>> we don't want it to be. To some extent, because it can't be. You are a
>> victim of "progress".
>> >
>> > Warm regards, and good luck;
>> >
>> > -M<
>> >
>> >
>> >
>> > On Wed, Sep 15, 2021 at 1:05 PM Paul E McNary via ARIN-PPML <
>> arin-ppml@arin.net> wrote:
>> > I need to make a slight correction.
>> > I am semi retired from our Internet company and my son runs the show.
>> > He is a triple major Engineer and is PE certifiable in each of the 3
>> areas.
>> > He says he has deployed IPv6 to subscribers.
>> > But Simple and Cheap NO.
>> > 5 years and a complete forklift to all subscribers.
>> > The issues happens at the head end router.
>> > My son is an University educated Enginner.
>> > His under graduate work was in Network Engineering.
>> > He was offered a bypass of Master's Degree and go straight into PHD
>> Network Engineering
>> > Graduated Summa Cum Laude, so he's not an Idiot
>> > Well maybe he is. He choose our WISP over the PHD.
>> > He says IPv6 does work for the last mile but on our redundant backhaul
>> loops it has some shortcomings.
>> > And our multi-homing has some issues with IPv6.
>> >
>> > Thought I would make these corrections.
>> > Just an old, fat, grumpy guy and former Guru that has outlived his
>> usefulness
>> > Paul McNary
>> >
>> > - Original Message -
>> > From: "arin-ppml" 
>> > To: sc...@solarnetone.org
>> > Cc: "arin-ppml" 
>> > Sent: Wednesday, September 15, 2021 11:44:09 AM
>> > Subject: Re: [arin-ppml] Change of Use and ARIN (was: Re: AFRINIC And
>> The Stability Of The Internet Number Registry System)
>> >
>> > > On Sep 14, 2021, at 22:50 , sc...@solarnetone.org wrote:
>> > >
>> > >
>> > >
>> > > On Tue, 14 Sep 2021, Owen DeLong wrote:
>> > >
>> > >>
>> > >>
>> > >>> On Sep 14, 2021, at 22:42 , sc...@solarnetone.org wrote:
>> > >>>
>> >  Nobody I know has found a way to do lossless packing of 128 bits
>> into a 32 bit field yet. Until you can achieve that, compatibility is
>> rather limited.
>> > 
>> >  Please present your solution here.
>> > >>>
>> > >>> Encode it in four sequential packets, 32 bits per, and add logic to
>> parse those malformed addresses in the routing daemons.
>> > >>
>> > >> Either I’m missing something, or that’s not going to be functional
>> when those 4 packets reach the IPv4-Only end host and it has to reply.
>> > >
>> > > Maybe, but that is not the challenge you presented:)
>> >
>> > Fair enough… In context, the challenge I presented was about getting an
>> IPv4-only host with no changes to software to be able to engage
>> > in bidirectional communication with remote hosts that live in a 128 bit
>> address space. Yes, you are correct the the way I abbreviated my
>> > expression of that particular challenge was not complete in itself
>> without the additional context.
>> >
>> > > Seriously, some manner of stateful 6/4 nat or header mangling is
>> going to be 

Re: [arin-ppml] Proposal - Remove Initial Small Assignment Requirements for IPv6

[David Farmer via ARIN-PPML]

I'm personally willing to take your word for it.

However, ARIN as an organization, can't do that. And it is in everyone's
interest that they enforce their due diligence and require proper
documentation. Otherwise, without such due diligence anyone could steal
resources from anyone else.

I feel for you, and it sucks, but unfortunately it has to be that way or
the entire registry system could fall apart.

Sorry.

On Wed, Sep 15, 2021 at 10:25 AM Paul E McNary via ARIN-PPML <
arin-ppml@arin.net> wrote:

> Can I at least get my 1 Legacy /24 that my dear colleague/friend gave me
> transferred to me with minimal documentation?
> See you proved my point nobody works together inside the beltway.
> Especially for some of us pioneers.
> :-(
> - Original Message -
> From: hostmas...@uneedus.com
> To: "Paul E McNary" 
> Cc: "Owen DeLong" , "arin-ppml" 
> Sent: Wednesday, September 15, 2021 3:01:35 AM
> Subject: Re: [arin-ppml] Proposal - Remove Initial Small Assignment
> Requirements for IPv6
>
> The only thing that ARIN can really do in your business plan is provide
> numbering resources.  The problems with sites, bandwidth, and other
> providers have little to do with ARIN.  However, other than the dedicated
> pools for IX's and IPv6, the pot is nearly dry so this is not going to
> help with your needs.  It is going to get expensive to get IPv4 space. The
> free pool ran out in February, 2011 and it is going to keep getting worse.
> Nothing that ARIN can do can produce more numbers from thin air.
>
> I also happen to use a WISP for network connectivity. They have been in
> business for about 15 years, so they already had enough IPv4 space to
> operate their small customers.  Prior to the free pool exhaust, they would
> send their commercial customers to ARIN for space.  Now there is a limit
> of 1 IPv4 per circuit.  If you need more, they will be glad to route, but
> you have to bring your own IPv4.
>
> It sounds like your WISP business is more recent.  Without enough IPv4,
> you have clearly discovered that it is very hard to operate.  I am
> guessing that in another 5 years or so, it might be possible to operate a
> good IPv6 service, with a CGnat for the then limited amount of IPv4 sites.
>
> To solve the medical providers access properly, you need to try to get the
> hospital and pharmacies and others that they need to communicate with onto
> IPv6. Some of this has already been happening indirectly, as those
> institutions choose to move to the cloud.  Most cloud providers are IPv6
> compatible.
>
> Centurylink and Windstream here offer dual stack over their circuits.
> There must be some kind of technical limitation at your end, maybe
> involving their upstream to the backbones.  Being in the 3rd largest
> state, we do not have as much issue, as competition has more or less
> forced all Internet Exchanges to adopt dual stack.
>
> Are you licensed, or are your radios Part 15?  My WISP is licensed, and
> that makes a BIG difference.  Unlicensed works when there are not others,
> but as you have discovered it does not protect you from interference.
> Even if you move to another tower that you own, there is no assurance that
> the interference will stop, especially if you operate point to multipoint
> like most WISPS.  I would suggest that you instead try to move at least
> some of your links to licensed, which may allow you to stay put. Start
> with the ones that have the most interference problems. If possible,
> unloading backhaul from microwave to fiber can also help with reliability.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
> On Wed, 15 Sep 2021, Paul E McNary via ARIN-PPML wrote:
>
> > Owen you did not even comprehend what I said.
> > That's the whole problem
> > You and ARIN never solved or advised me on I what I needed to do just a
> lot of side stepping like you just twisted completely incorrectly.
> > I guess Midwest English is too different than your and Washington DC's
> English.
> > Go back and translate to Midwest English.
> > Even Centurylink doesn't provide local DSL IPv6.
> > Between Centurylink and WindStream they have been our best sales people
> until the COOP's started overbuilding.
> > The 2 of them cover 90% of our coverage area and rural DSL from both of
> them do not offer IPv6
> > We offer more than the big companies you so talk about.
> > Some commercial fiber customers can get either IPv6 or IPv4 but not dual
> stack out here in the sticks.
> > Our Fiber supplier network was built out for hospitals and schools. Big
> money contract.
> > The last independent doctor had us switch our from the hospital's DSL to
> our Wireless because Centurylink could take days
> > to get his connection to the hospital network. Now all the Doctor's are
> hospital slaves. They are always in different hospital
> > clinics many miles apart and sometime 2 clinics a day.
> > Where the Independent Doctor, I was on his cell phone and he had my
> personal cell phone.
> > If he 

Re: [arin-ppml] Proposal - Remove Initial Small Assignment Requirements for IPv6

[David Farmer via ARIN-PPML]

No, thank you for the effort in writing the proposal, while I think it goes
too far by eliminating 6.5.8.1 altogether, it has been about 10 years since
6.5.8.1.c & d were put in place with ARIN-2010-8 and about 5 years
since 6.5.8.1.e was put in place with ARIN-2015-1. It wouldn't hurt at all
to review those criteria and make sure they meet the community's needs
today. Furthermore, if you think we need to clarify "active use" that is
perfectly appropriate, we could have easily oversimplified the criteria to
the point people new to policy don't really understand what we mean. If
that is the case, that is really good feedback.

My suggestion is to work with the AC Shepherds and focus on
reviewing 6.5.8.1.c-e. If it was me, I would propose cutting the number in
"c" and "d" in half as a starting point for the discussion, the IPv4
initial allocation criteria have changed significantly since ARIN-2010-8. I
think "e" is probably about right but if you have other ideas let's hear
them, and if you have ideas for better wording let's hear that too.  There
is nothing sacred about those numbers or those criteria, but I think there
is strong agreement that there needs to be some kind of criteria that
single-homed end-users need to meat

Thanks.

On Mon, Sep 13, 2021 at 2:05 PM Larry R. Dockery 
wrote:

> Thank you for your time in providing this information. This is the best
> argument against the proposal.
>
>
>
> If this is a significant issue and holds true, then 1) most organizations
> do not and should not qualify for PI space. And 2) These orgs should, per
> the design recommendation in “IPv6 Address Planning”, use NTPv6 with ULA
> internally to avoid ISP lock-in inherent with IPV6 PA space.
>
>
>
> This is far better than IPv4 NAT + RFC1918 in that it is stateless, but is
> an unfortunate workaround that somewhat inhibits the end-to-end principle.
>
>
>
> That would be an unfortunate end-state for IPv6 that most SMB’s are still
> behind NAT, but may be the best technical way forward.
>
>
>
>
>
> *From:* David Farmer 
> *Sent:* Monday, September 13, 2021 10:32 AM
> *To:* Larry R. Dockery 
> *Cc:* arin-ppml@arin.net
> *Subject:* Re: [arin-ppml] Proposal - Remove Initial Small Assignment
> Requirements for IPv6
>
>
>
> The intent behind section 6.5.8.1 is not to conserve IPv6 address space
> but to conserve slots in the IPv6 route table, AKA the default-free zone.
> The abundance of /48s and /44s, or /40s, /36s, /32s for that matter, are
> irrelevant, there is only a finite number of routing slots available. BGP
> multihomed end-users will use a routing slot regardless of the source of
> the address space they use, so it is best if it comes from an RIR. However,
> single-homed end-users can be aggregated by their provider, yes this comes
> at a cost of renumbering for those end-users, but eliminating renumbering
> for those end-users comes at a cost of an IPv6 routing slot for the entire
> Internet. Therefore the cost of renumbering born by the end-user has to be
> balanced against the cost of a routing slot born by the entire Internet.
>
>
>
> The IPv6 route table is currently growing quite quickly, see the following;
>
>
> https://blog.apnic.net/2021/03/03/what-will-happen-when-the-routing-table-hits-1024k/
>
> https://blog.apnic.net/2021/01/05/bgp-in-2020-the-bgp-table/
>
> https://blog.apnic.net/2020/01/14/bgp-in-2019-the-bgp-table/
>
>
> https://labs.ripe.net/author/stephen_strowes/visibility-of-ipv4-and-ipv6-prefix-lengths-in-2019/
>
> https://bgp.potaroo.net/v6/as2.0/index.html
>
> https://www.space.net/~gert/RIPE/weekly/2021/37/
>
>
>
> The current 6.5.8.1.c was adapted from the IPv4 requirements when Draft
> Policy 2010-8: Rework of IPv6 assignment criteria was adopted.  At that
> time IPv4 slow-start was still in effect, and there was still an IPv4 free
> pool. When the IPv4 transfer market became the primary source of IPv4
> address space, slow-start was no longer practical or functional, and the
> initial allocation for IPv4 was changed. However, for IPv4 there is now the
> additional cost of obtaining the IPv4 block on the transfer market which
> somewhat offsets the removal to slow-start at least to some extent.
>
>
>
> So, while I do not support the wholesale removal of section 6.5.8.1, I
> would support relaxing, possibly significantly relaxing, or otherwise
> modifying 6.5.8.1.c-e which are the current technical qualification for
> non-multihomed end-users. Fundamentally, it is not practical to have every
> business that could afford to pay ARIN's fees to avoid renumbering and to
> receive an IPv6 routing slot. It is not even entirely clear, there will be
> sufficient IPv6 routing slots for every end-user that is willing to BGP
> multi-home.
>
>
>
> Therefore, I believe there needs some kind of technical criteria that a
> non-multihomed end-user needs to meet to qualify to receive a Provider
> Independent IPv6 Allocation, and it needs to be more than just the ability
> to pay ARIN's fees.
>
>
>
> 

Re: [arin-ppml] Proposal - Remove Initial Small Assignment Requirements for IPv6

[David Farmer via ARIN-PPML]

The intent behind section 6.5.8.1 is not to conserve IPv6 address space but
to conserve slots in the IPv6 route table, AKA the default-free zone. The
abundance of /48s and /44s, or /40s, /36s, /32s for that matter, are
irrelevant, there is only a finite number of routing slots available. BGP
multihomed end-users will use a routing slot regardless of the source of
the address space they use, so it is best if it comes from an RIR. However,
single-homed end-users can be aggregated by their provider, yes this comes
at a cost of renumbering for those end-users, but eliminating renumbering
for those end-users comes at a cost of an IPv6 routing slot for the entire
Internet. Therefore the cost of renumbering born by the end-user has to be
balanced against the cost of a routing slot born by the entire Internet.

The IPv6 route table is currently growing quite quickly, see the following;
https://blog.apnic.net/2021/03/03/what-will-happen-when-the-routing-table-hits-1024k/
https://blog.apnic.net/2021/01/05/bgp-in-2020-the-bgp-table/
https://blog.apnic.net/2020/01/14/bgp-in-2019-the-bgp-table/
https://labs.ripe.net/author/stephen_strowes/visibility-of-ipv4-and-ipv6-prefix-lengths-in-2019/
https://bgp.potaroo.net/v6/as2.0/index.html
https://www.space.net/~gert/RIPE/weekly/2021/37/

The current 6.5.8.1.c was adapted from the IPv4 requirements when Draft
Policy 2010-8: Rework of IPv6 assignment criteria was adopted.  At that
time IPv4 slow-start was still in effect, and there was still an IPv4 free
pool. When the IPv4 transfer market became the primary source of IPv4
address space, slow-start was no longer practical or functional, and the
initial allocation for IPv4 was changed. However, for IPv4 there is now the
additional cost of obtaining the IPv4 block on the transfer market which
somewhat offsets the removal to slow-start at least to some extent.

So, while I do not support the wholesale removal of section 6.5.8.1, I
would support relaxing, possibly significantly relaxing, or otherwise
modifying 6.5.8.1.c-e which are the current technical qualification for
non-multihomed end-users. Fundamentally, it is not practical to have every
business that could afford to pay ARIN's fees to avoid renumbering and to
receive an IPv6 routing slot. It is not even entirely clear, there will be
sufficient IPv6 routing slots for every end-user that is willing to BGP
multi-home.

Therefore, I believe there needs some kind of technical criteria that a
non-multihomed end-user needs to meet to qualify to receive a Provider
Independent IPv6 Allocation, and it needs to be more than just the ability
to pay ARIN's fees.

And for clarity, I do not support the proposal as written.

Thanks.

On Mon, Sep 13, 2021 at 9:51 AM Larry R. Dockery 
wrote:

> https://www.arin.net/participate/policy/proposals/2021/ARIN_prop_301_orig/
>
>
>
> I would like to hear community feedback on this proposal. Thank you.
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

[arin-ppml] Big news for St. Helena

[David Farmer via ARIN-PPML]

There is big news for St. Helena, in the ARIN Region, Outlying Areas
Sector, the Google Equiano Cable has landed on St Helena.

https://www.saint.fm/googles-equiano-fibre-optic-cable-lands-on-st-helena/

https://cloud.google.com/blog/products/infrastructure/introducing-equiano-a-subsea-cable-from-portugal-to-south-africa

https://www.arin.net/about/welcome/region/

https://en.m.wikipedia.org/wiki/Saint_Helena

Congratulations to the people of St. Helena!

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

[arin-ppml] Change of Use and ARIN (was: Re: AFRINIC And The Stability Of The Internet Number Registry System)

[David Farmer via ARIN-PPML]

I changed the subject line, as this isn't directly related to the dispute
between AFRINIC and CI, but more some questions arising from it
specifically related to the ARIN registered resources.


So, do ARIN resource holders have a duty to report changes in their use of
resources? If they do, where does that duty come from in policy or contract
language? And, what are the relevant changes that need to be reported?

In my review of these questions;

In the RSA I see where holders are granted, "The right to use the Included
Number Resources within the ARIN database" (RSA section 2.b bullet 2).
However, I don't see any limitation to that use, such as "originally
justified" or any obligation to report a change in such use.

In policy, "An end-user is an organization receiving assignments of IP
addresses exclusively for use in its operational networks." (NRPM 2.6),
with an exception for incidental or transient use (last paragraph, section
2.5).

Maybe to align end-user requirements with the new Registration Services
Agreement we should change that so end-users have to report any use, other
than incidental or transient use, outside their organization.

And ISP's have requirements to report the use by their customers that
exceed certain levels (NRPM sections 4.2.3.7 and 6.5.5).

So, other than the ISP reporting requirements, I don't see direct reporting
obligations for change in use. Further, I don't see any guidance to what
might be a material change in use that is in need of reporting, as I'm sure
we don't want ARIN Staff tied up with reports of all possible changes, most
of which are probably irrelevant.

Are there reporting requirements I'm missing? Maybe implied or indirect
requirement?

Should something be added to ARIN's policies explicitly stating
requirements for reporting a change in the use of resources?

Thanks

On Wed, Sep 1, 2021 at 11:27 AM John Curran  wrote:

> On 31 Aug 2021, at 10:59 PM, arin-ppml@arin.net wrote:
>
> ...
> If Cloud Innovation has indicated that they predominantly “lease” the IP
> address space to other parties, then why did AfriNic grant their request in
> the first place, if it violates their policy ?
>
>
> Michel -
>
> That presumes that Cloud Innovation actually requested the address space
> for that purpose, and hence why many are asking Cloud Innovation (and those
> associated with CI) the question "*Is Cloud Innovation’s use of the
> blocks in question within the remit and purpose for which they were
> originally justified?”*
>
> It is a simple yes/no question of fact, but one which has alluded any
> official answer to date.  It’s been suggested that they’ve already said as
> much in previous emails, but a simple yes/no response doesn’t seem
> forthcoming – although it would certainly clarify quite a bit.
>
>
> FYI,
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

[arin-ppml] Draft Policy ARIN-2020-7 4.4 gTLD Micro-allocation Clarification

[David Farmer via ARIN-PPML]

I support this policy as written.--
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

[arin-ppml] Draft policy ARIN-2020-6 Allowance for IPv4 Allocation “Swap” Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR Transfers

[David Farmer via ARIN-PPML]

I support the intent of this policy.

I suggest the addition of the word “pre-approved” to the text that is added
to Sections 8.3 and 8.4.

... transferring resources as part of a pre-approved renumbering plan...

According the comments provided in policy, ARIN staff currently requires
pre-approval for this practice, and I believe that is appropriate and the
policy should explicitly require pre-approval for this practice.
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

[arin-ppml] Recommend Draft Policy ARIN-2020-8 Clarify and Update 4.2.1.2 Annual Renewal Fee

[David Farmer via ARIN-PPML]

On the web page for ARIN-2020-8, under the Staff and Legal Review, the
third bullet under Implementation Requirements, refers to ARIN-2020-6 and
seems to be relevant to that policy and not this policy, I believe this to
be a cut-and-past error.

https://www.arin.net/participate/policy/drafts/2020_8/

Thanks.
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2020-8: Clarify and Update 4.2.1.2 Annual Renewal Fee

[David Farmer via ARIN-PPML]

I also support these changes.

On Fri, Nov 20, 2020 at 12:23 PM Chris Woodfield 
wrote:

> FD: This policy is a work produce of the AC’s Policy Experience Report
> working group, which I currently chair.
>
> Taking my AC/WG chair hat off, I am in support of the updated language,
> with the caveat that the following assumptions can be relied upon:
>
> 1. The added language cannot be interpreted to place additional conditions
> on legacy resource holders that do not exist today. I’m interpreting the
> reference to resources “allocated and assigned under these policies” as
> implicitly excluding legacy resource holders, but please correct me if that
> assumption is incorrect.
>

I believe that is the intent of the language. Since legacy resources were
allocated prior to the creation of ARIN, they weren't "allocated or
assigned under these policies." On the other hand, just to be clear, the
lack of a formal written agreement for legacy resource holders doesn't
necessarily imply there is no agreement at all. There are lots of things in
the world done by informal agreements, for example, a handshake agreement.


> 2. The term “Registration Services Agreement” is used generically, and is
> inclusive of RSA and LRSA agreements, or other future agreements ARIN may
> have with resource holders.
>

I believe that is the intent as well. However, I think the issue of future
agreements is an important point that might be worth adding to the text.
How about something like this;

This, or future, agreements cover the terms, rights, responsibilities, and
conditions of service; failure to adhere to the RSA may result in
revocation of number resources.


Thanks

Thanks,
>
> -C
>
> On Nov 20, 2020, at 9:55 AM, ARIN  wrote:
>
> The following Draft Policy has been revised:
>
> * ARIN-2020-8: Clarify and Update 4.2.1.2 Annual Renewal Fee
>
> Revised text is below and can be found at:
>
> https://www.arin.net/participate/policy/drafts/2020_8/
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion in order 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,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
>
> Draft Policy ARIN-2020-8: Clarify and Update 4.2.1.2 Annual Renewal Fee
>
> Problem Statement:
>
> The January 2020 Policy Experience Report highlighted that the existing
> language in Section 4.2.1.2 "Annual Renewal" references fees. Fees are not
> considered a member qualification criteria. Since fees aren't referenced
> elsewhere in community policy, the wording was reviewed by the PEG.
>
> Policy Statement:
>
> Given that the Registration Services Agreement (RSA) already contains
> language regarding fees, the AC Shepherds recommend to eliminate 4.2.1.2.
> entirely and add:
>
> 2.X Registration Services Agreement (RSA)
>
> Number resources allocated or assigned by ARIN under these policies are
> subject to a Registration Services Agreement (RSA) between ARIN and the
> resource holder. This agreement covers terms, rights, responsibilities and
> conditions of service; failure to adhere to the RSA may result in
> revocation of number resources.
>
> Comments:
>
> The AC’s understanding is that community policy should not include
> language referring to fees, as such language is already present in the
> Registration Services Agreement (RSA)
>
> Registration Services has informed us that "Section 4.2.1.2. contains
> language detailing fee due dates, encouraging on-time payments, and
> mentions potential revocations. It also contains a reference to web
> documentation that has evolved significantly since this policy was
> implemented, and may continue to do so. Essentially the entire section is
> made of language that is already in the Registration Services Agreement,
> and is generally fee-focused, making it outside normal scope for Internet
> number resource policy."
>
> Timetable for Implementation: Immediate
>
> Anything Else: Community input since adopting draft has informed this
> direction. The 2.X placeholder is used as this seems like it might be
> foundational enough to not be 2.17 but the Shepherds would rather not upset
> current indexing arbitrarily.
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if 

Re: [arin-ppml] Recommended Draft Policy ARIN-2020-2

[David Farmer via ARIN-PPML]

To clarify, I believe your voice counts, even if you only ever participate
in this single issue. I was suggesting, that more participation is even
better and that it also takes away that argument from those that perceive
single-issue participation as an issue.

Sorry, if that wasn't clear on my part.

On Wed, Nov 4, 2020 at 12:29 PM Jason Baugher 
wrote:

> As an organization that decided to support ARIN-2020-2, this was also our
> first foray into participation in this group. We never expected the
> response we’ve had to what seemed like it would be an honest policy debate.
> In additionl to someone accusing companies like us of taking “incentives”
> from Stratus for support, another implied that we shouldn’t have a voice
> because we are a “single-issue participant”. I would remind them that
> everyone on this list was a single-issue participant the first time they
> spoke up in favor or against a policy change, and we have just as much
> right as everyone else to have a voice here. If you wonder why more orgs
> don’t participate in these policy discussions, maybe look at how this
> particular debate has proceeded for your answer.
>
>
>
> Stratus has offered us no incentives. As an ISP in their region, they
> merely reached out to us, asked that we look at the information for
> ourselves, and if we agreed, to voice our support. Whether ARIN-2020-2
> succeeds or fails has no impact on our operations. We support it strictly
> on its merits.
>
>
>
> Jason
>
>
>
> *From:* ARIN-PPML  *On Behalf Of *Eric Lee
> *Sent:* Monday, November 2, 2020 1:20 PM
> *To:* arin-ppml@arin.net
> *Subject:* [arin-ppml] Recommended Draft Policy ARIN-2020-2
>
>
> CAUTION: This email is from OUTSIDE our organization.
> Please do not open/download any attachment or click any link unless you
> know it's safe.
>
>
> In response to David, I think it's important that entities be involved in
> the process. I was unaware of an ability to have a voice until this issue.
> It's important that we become engaged in this community as the issues are
> important to all. Whether it's this issue, the discussion of IPV6 or other
> methods of tackling the IP space issue, or any other matter addressed in
> this forum, we should all be working together to resolve those issues by
> giving our input. If entities become engaged in the broader forum because
> of this topic, then that's not necessarily a bad thing.
>
> In response to Tom, he describes it fairly. There was nothing from Stratus
> other than a request for support and information about how to get involved.
> There was no follow-up from them on the request. We determined that the
> issue had merit and put our support behind it.
>
> -Original Message-
> From: ARIN-PPML On Behalf Of arin-ppml-requ...@arin.net
> Sent: Monday, November 2, 2020 12:05 PM
> To: arin-ppml@arin.net
> Subject: ARIN-PPML Digest, Vol 185, Issue 6
>
> Send ARIN-PPML mailing list submissions to
> arin-ppml@arin.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
> arin-ppml-requ...@arin.net
>
> You can reach the person managing the list at
> arin-ppml-ow...@arin.net
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
> 1. Re: Last Call - Recommended Draft Policy ARIN-2020-2:
> Reinstatement of Organizations Removed from Waitlist by
> Implementation of ARIN-2019-16 (David Farmer)
> 2. Re: Oppose Draft Policy ARIN-2020-2 (John Santos)
> 3. Re: Oppose Draft Policy ARIN-2020-2 (Joe Provo)
> 4. Re: Recommended Draft Policy ARIN-2020-2: Reinstatement of
> Organizations Removed from Waitlist by Implementation of
> ARIN-2019-16 (Tom Pruitt)
> 5. Re: Oppose Draft Policy ARIN-2020-2 (Martin Hannigan)
>
>
> --
>
> Message: 1
> Date: Mon, 2 Nov 2020 11:06:06 -0600
> From: David Farmer
> To: ARIN-PPML List
> Subject: Re: [arin-ppml] Last Call - Recommended Draft Policy
> ARIN-2020-2: Reinstatement of Organizations Removed from Waitlist by
> Implementation of ARIN-2019-16
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
>
> As I have said before, I believe that the implementation of ARIN-2019-16
> was fair, more precisely, I believe it was objectively fair. Nevertheless,
> I think we can all acknowledge that subjectively, it never quite seems fair
> when you're the one that ends up with the short end of the stick, however
> objectively fair the decision actually was. Accordingly, I have some
> empathy for those that ended up with the short end of the stick in this
> situation, through no fault of their own, and support this policy to
> restore at least some of those dropped from the waiting list by the
> implementation of ARIN-2019-16, even though I don't think we can or should
> restore everyone that was dropped.
>
> Further, more 

Re: [arin-ppml] Last Call - Recommended Draft Policy ARIN-2020-2: Reinstatement of Organizations Removed from Waitlist by Implementation of ARIN-2019-16

[David Farmer via ARIN-PPML]

As I have said before, I believe that the implementation of ARIN-2019-16
was fair, more precisely, I believe it was objectively fair. Nevertheless,
I think we can all acknowledge that subjectively, it never quite seems fair
when you're the one that ends up with the short end of the stick, however
objectively fair the decision actually was. Accordingly, I have some
empathy for those that ended up with the short end of the stick in this
situation, through no fault of their own, and support this policy to
restore at least some of those dropped from the waiting list by the
implementation of ARIN-2019-16, even though I don't think we can or should
restore everyone that was dropped.

Further, more participation is always a good thing for the Policy
Development Process (PDP). However, there is at least the perception that
many of the new participants are participating in the discussion of only
this single issue, if true, this is not healthy participation, this
perception concerns me. My suggestion to these new participants is, for you
to combat this perception by reviewing and commenting on the many other
policies under discussion. Please don't allow yourself to be tagged, and
possibly dismissed, as a single-issue participant.

Thank you.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN 2020-3

[David Farmer via ARIN-PPML]

You don't have to be an ISP to have an ASN, thousands of end-users have
ASNs assigned to them by ARIN, in ARIN policy the difference between an ISP
(AKA an LIR) and an end-user is the ability to reassign address space to
other entities.  Since an end-user doesn't assign address space to other
entities a /44 or even a /48 assignment directly from ARIN makes sense,
such a small allocation to an ISP makes no sense since they
couldn't reassign /48s to a sufficiently large number of customers. The
point of this policy is to allow extremely small ISPs to receive a /40,
providing 256 /48s for reassignment, which is a viable IPv6 allocation for
the very smallest ISPs.

I hope that clarifies things for you.

Thanks.

On Mon, Oct 12, 2020 at 4:30 PM  wrote:

> Andrew,
>
> On Mon, 12 Oct 2020, Andrew Dul wrote:
>
> > On 10/12/2020 1:29 PM, sc...@solarnetone.org wrote:
> >> Hi Andrew,
> >>
> >> On Mon, 12 Oct 2020, Andrew Dul wrote:
> >>
> >>> The partial returns language is also intended to promote best practices
> >>> for IPv6 addressing, that is giving big blocks to allow ISPs to assign
> >>> /48s to all customers.
> >>
> >> True, but not all resource holders are operating ISP's for public use.
> >> For example, my local City Government has an ASN, and v4 address
> >> block. They provide no internet services, neither network, to eyes,
> >> nor content other than for their own use.  This is the case with many
> >> resource holders not in the primary business of being an ISP.
> >>
> >> Scott
> >>
> > The organization you describe here sounds more like an end-user, but I
> > do understand various organizations have switched from being an end-user
> > to ISP and vise-versa over the years for various reasons.
>
> Unfortunately, the only way to have redundancy in your upstream while
> keeping connectivity to your network address is to be an ISP by this
> definition, even if you offer no network services to other organizations.
> This is because an AS is required to perform BGP, which is critical to
> maintaining connectivity to a multi-homed network through outage of one
> or more connected circuits.
>
> >
> > An end-user organization who would be eligible to obtain an /48 under
> > 6.5.8 of the NRPM.
> >
> >
> https://www.arin.net/participate/policy/nrpm/#6-5-8-direct-assignments-from-arin-to-end-user-organizations
> >
> > This draft policy ARIN-2020-3 is specifically related to ISPs.
>
> I believe you are making a misclassification here.  Once these
> organizations have AS and/or address resources, they are considered an ISP
> for these purposes, despite their end use case.
>
> Scott
>
> >
> >
> >>>
> >>> Andrew
> >>>
> >>> On 10/12/2020 12:26 PM, sc...@solarnetone.org wrote:
>  Hi Chris,
> 
>  I wonder what percentage of 2x-small Resource holders have a /24 of
>  v4, and would otherwise qualify for 3x-small status but for their v6
>  allocations, and what percentage of all ASs registered with ARIN that
>  represents.  This represents the the total who could "downgrade" to a
>  nano-allocation, were that a option.  It would be easy to derive from
>  that the maximum effect on ARIN's finances, if they all chose to take
>  that option.
> 
>  Scott
> 
>  On Mon, 12 Oct 2020, Chris Woodfield wrote:
> 
> > Agreed. To be clear, I did not intend for my question to imply that
> > the goal of keeping the proposal revenue-neutral was in any way
> > dishonorable - ARIN’s financial stability is obviously in the
> > community’s best interests. But we should have informed consent as to
> > how that stability is achieved, and as such, clarifying the intention
> > of the clause is helpful.
> 
> 
> 
> >
> > Thanks,
> >
> > -C
> >
> >> On Oct 12, 2020, at 11:06 AM, sc...@solarnetone.org wrote:
> >>
> >> Hi Chris,
> >>
> >> Indeed.  To be fair, I think the price is fair for value received,
> >> speaking as a 2x-small ISP with a /36.  I was able to lower my
> >> recurring costs and increase my available address pool by bringing
> >> up an AS at the 2x-small rate.  Allowing the smallest ISPs to
> >> implement IPv6 without additional financial cost seems a prudent way
> >> to overcome barriers to adoption.
> >>
> >> Scott
> >>
> >> On Sun, 11 Oct 2020, Chris Woodfield wrote:
> >>
> >>> Thanks Andrew, and good catch - both Scott and I missed that
> >>> clause, obviously. It appears that this is in place in order to
> >>> meet the stated goal of this proposal being revenue-neutral for
> >>> ARIN? If so, it would be great to clarify so that community members
> >>> can make a more informed evaluation as to whether or not to support
> >>> the clause. If there are other justifications for the clause’s
> >>> presence, I’d be interested to hear them.
> >> 2~>
> >>> Thanks,
> >>>
> >>> -C
> >>>
>  On Oct 11, 2020, at 10:24 

Re: [arin-ppml] Inter-RIR transfer Policy compatibility with Afrinic_Resource Transfer Policy proposal

[David Farmer via ARIN-PPML]

I think it is questions of process, how would we feel if AFRINIC commented
on one of our policies on their policy list? Further, a staff evaluation is
a formal process because generally, RIR staff don't comment about a policy
proposal except through such a formal evaluation. There are very good
reasons, staff evaluations go through a formal process, staff should only
plan a very limited roll in the formation of RIR policy.  Yes, in some
situations this is inconvenient, but there is a strong reason for this
inconvenience, and why there is a PDP.

Thanks

On Mon, Oct 12, 2020 at 12:12 PM Mueller, Milton L 
wrote:

> John
>
> Would it be so difficult to send the ARIN staff evaluation to the list?
>
>
>
> *From:* ARIN-PPML  *On Behalf Of *John
> Sweeting
> *Sent:* Saturday, October 10, 2020 3:47 PM
> *To:* Anthony Ubah ; arin-ppml@arin.net
> *Cc:* Taiwo Oyewande 
> *Subject:* Re: [arin-ppml] Inter-RIR transfer Policy compatibility with
> Afrinic_Resource Transfer Policy proposal
>
>
>
> Hello Authors,
>
>
>
> ARIN has provided AFRINIC staff our evaluation of the policy below. Please
> reach out to AFRINIC staff for ARIN’s evaluation.
>
>
>
> Thank you,
>
>
>
> John Sweeting
>
> CCO, ARIN
>
>
>
> *From: *ARIN-PPML  on behalf of Anthony Ubah <
> ubah.tonyi...@gmail.com>
> *Date: *Saturday, October 10, 2020 at 11:56 AM
> *To: *"arin-ppml@arin.net" 
> *Cc: *Taiwo Oyewande 
> *Subject: *[arin-ppml] Inter-RIR transfer Policy compatibility with
> Afrinic_Resource Transfer Policy proposal
>
>
>
> Hello ARIN,
>
> We are the authors of the Resource Transfer Policy, which is the inter-RIR
> transfer proposal that has just reached consensus within Afrinic, and we
> are reaching out to you to inquire about its reciprocity with ARIN.
>
> Feedback of your assessment and analysis of this proposal would be highly
> appreciated.
>
> Please find below the proposal for your reference.
>
> We are looking forward to hearing from you.
>
>
>
> *Draft Below..*
>
>
>
> Resource Transfer Policy
>
> Authors: Anthony Ubah & Taiwo Oyewande
>
> Submission date: 21/09/2020
>
> Version: 2.0
>
> Amends: CPM 5.7
>
>
>
> *1. Summary of the problem being addressed by this proposal*
>
> The current policy fails to support a two-way Inter-RIR policy, thereby
> hindering smooth business operation, development, and growth in the region.
> This proposal aims to establish an efficient and business-friendly
> mechanism to allow number resources to be transferred from/to other
> regions. This proposal outlines a model in which AFRINIC can freely
> transfer number resources to/from other regions, i.e. RIPE NCC, APNIC, ARIN
> and LACNIC. This includes both IPv4 addresses and AS numbers.
>
>
>
> *2. Summary of how this proposal addresses the problem*
>
> With the exhaustion of IPv4, several regions have adopted a transfer
> policy to accommodate the shortage of resources. Number resources are
> allowed to transfer within the region itself, as well as with other regions.
>
> Such practice is effective and necessary when we are facing a shortage of
> resources. This helps facilitate business operations while reducing prices.
>
> Such Inter-RIR transfer, however, is not yet established in AFRINIC. This
> hinders business operation and development within the African region. The
> current proposal aims to establish an efficient and business-friendly
> mechanism to allow number resources to be transferred from/to other
> regions. Before moving to illustrate how this new mechanism works, let’s
> take a quick look at the situation of the current Consolidated Policy
> Manual:
>
> In Consolidated Policy Manual updated on 22 Feb 2019, only “IPv4 resources
> transfer within the AFRINIC region” is mentioned.
>
> Regarding resource transfer to other regions, only the following is
> mentioned:
>
> 5.5.1.1.3 If an LIR plans to exchange or transfer address space, it needs
> to contact AFRINIC so that the changes are properly registered.
>
> The LIR remains responsible for all the allocations registered in the
> AFRINIC database until they have been transferred to another LIR or
> returned to AFRINIC. LIR's must ensure that all policies are applied.
>
> The lack of a clear guideline of resource transfer is detrimental to the
> continent’s development. It makes business operation difficult and it also
> hinders new business from establishing in the region.
>
> Also, as Inter RIR policy is enforced in other regions, it is important
> that AFRINIC keeps up with other RIRs to ensure smooth operation and
> coordination.
>
>
>
> 3. Proposal
>
> CPM 5.7 will be modified by this proposal as follows:
>
>
>
> *5.7 IPv4 Resources resource transf*er
>
>
> Like the other Regional Internet Registries, AFRINIC will soon exhaust its
> IPv4 pool. In order to meet the needs of late resource requestors, a
> transfer policy for IPv4 resources within and outside the region is needed.
> The goal of this policy is to define conditions under which transfers must
> occur. The policy solves the 

Re: [arin-ppml] RIPE enforcing court-ordered "right to register"

[David Farmer via ARIN-PPML]

I wouldn't say RIPE took the financial transaction or the contract between
the parties into consideration, the Judge did.

A few comments;

1. It is highly likely, maybe even expected in many cases, that the two
parties involved in a transfer will have a contract, either written or
verbal.

2. Neither ARIN nor the other RIRs are going to agree to be parties to this
contract.

3. Nor will ARIN or the other RIRs agree to be the arbitrator of this
contract.

4. Therefore it is not ARIN or the other RIRs duty to enforce any terms of
this contract unless ARIN or the other RIRs are ordered to do so by a court
of competent jurisdiction.

5. In other words, if terms of the contract need to be enforced it is the
aggrieved parties responsible to obtain a court order from the appropriate
court ordering ARIN or the other RIRs to appropriately do so.

6. The court decides who is right and who is wrong and what the appropriate
resolution of the dispute is, not ARIN or the other RIRs, they simply
follow the court's orders in most cases. Of course, ARIN or the other RIRs
can appeal if they feel the issue was decided incorrectly, but that is
probably a rare corner case.

Thanks

On Mon, Oct 5, 2020 at 12:59 PM Mike Burns  wrote:

> Hi Fernando,
>
>
>
> But RIPE did exactly that, took into consideration a financial transaction
> and then executed a transfer against the resource holder’s permission.
>
> RIPE did so at a judge’s order.
>
>
>
> We have judges in ARIN territory, too.
>
> What if the judge applied local contract law and issues an order to return
> the block to the original seller?
>
> If the right to register is just another alienable asset, should ARIN have
> policies that tend to work against the existing legal framework?
>
>
>
> I think ARIN should allow for the repossession of transferred blocks whose
> buyers breached contracts calling for post-transfer payment, if a judge
> orders this to happen, without letting policy get in the way.
>
>
>
> Regards,
> Mike
>
>
>
>
>
>
>
>
>
>
>
> *From:* ARIN-PPML  *On Behalf Of *Fernando
> Frediani
> *Sent:* Monday, October 05, 2020 1:24 PM
> *To:* arin-ppml@arin.net
> *Subject:* Re: [arin-ppml] RIPE enforcing court-ordered "right to
> register"
>
>
>
> RIRs should not take in consideration if there was a financial transaction
> between two organizations or not in order to proceed with the transfer (not
> talking about M). That should be an irrelevant detail to the RIR.
>
> In a simplified way RIRs should restrict themselves to check:
>
> 1) Did the transfer request came from the rightful resource holder ? If
> yes, then.
> 2) Does the transfer request comply with the current RIR policies ? If yes
> then pay the RIR fees and register the resources to the new resource holder.
>
> In this sense if there was a financial transaction the current resource
> holder should only request the RIR to transfer the resources when he is
> sure whatever has been agreed to be paid was already done.
>
> Fernando
>
> On 05/10/2020 12:36, Mike Burns wrote:
>
> Hi Fernando,
>
>
>
> Thanks for your thoughts, but there is no needs test in RIPE of course.
>
> And in fact, some entity did come to RIPE with a valid court order that
> said “Register is because I paid for it.”
>
> So there were no policy issues in that case.
>
>
>
> In ARIN, we can suppose the buyer was able to justify, but what happens if
> the buyer pays and does not get the addresses?
>
> If the buyer is in Canada, can a Canadian judge order ARIN to register the
> blocks to the buyer?
>
>
>
> And the more important question as to whether ARIN would re-register
> blocks back to a seller who doesn’t get paid?
>
> That would involve policy questions, I think.
>
>
>
> Regards,
> Mike
>
>
>
>
>
>
>
>
>
> *From:* ARIN-PPML 
>  *On Behalf Of *Fernando Frediani
> *Sent:* Monday, October 05, 2020 10:55 AM
> *To:* arin-ppml@arin.net
> *Subject:* Re: [arin-ppml] RIPE enforcing court-ordered "right to
> register"
>
>
>
> I am not sure exactly about RIPE but any court must take in consideration
> that the RIR policies must apply for the "buyer" to have the right to
> register it. Since in most RIRs the golden rule is (and must keep being) be
> able to justify for the addresses being received (either via a donation or
> a purchase).
>
> Nobody should ever be able to come to the RIR and say: "Register it
> because I paid for". The community who is the one that matters and make the
> rules is interested the addresses being transferred are going be really
> used for its final propose and get people connected to the internet,
> therefore it has a justification and not less important to be fair with all
> others.
> Just having the right to register addresses because it paid for it doesn't
> make sense and should be opposed as much as possible by all RIRs.
>
> Thankfully RIPE seems to go in that direction when they say in the
> statement: "*Finally, it’s worth noting that each order will be reviewed
> on a case by case basis. If we believe that 

Re: [arin-ppml] Draft Policy ARIN-2020-8: Clarify and Update 4.2.1.2 Annual Renewal Fee

[David Farmer via ARIN-PPML]

Well, on closer examination, while the acronym RSA is not
explicitly defined, two of the three uses of the acronym are in section
8.5.1 entitled Registration Services Agreement. Nevertheless, I think it is
a good idea to add a definition of the term Registration Services Agreement
and the acronym RSA to section 2.

On Tue, Aug 25, 2020 at 3:46 PM David Farmer  wrote:

> I believe Section 4.2.1.2 should be completely removed.
>
> The issues of Annual Renewal is not exclusive to IPv4 or to ISPs, for that
> matter, and therefore belongs somewhere else, maybe someplace in Sections 1
> or 2.  I also note that the term RSA is used in several locations and is
> not defined.  Therefore I suggest we add a new definition to Section 2, as
> follows;
>
> 2.X Registration Services Agreement (RSA)
>
> All resources allocated by ARIN through the included policies are subject
> to a Registration Services Agreement (RSA) between ARIN and the resource
> holder. This agreement includes the ability and the terms under
> which resources are revoked, including the lack of payment of annual fees.
>
>
> This definition clarifies the relationship between ARIN's Policies and the
> RSA agreement, additionally calling out the existence of fees and that
> resources are revoked through the terms of the RSA.
>
> Thanks
>
> On Tue, Aug 25, 2020 at 1:41 PM ARIN  wrote:
> ...
>
>> Draft Policy ARIN-2020-8: Clarify and Update 4.2.1.2 Annual Renewal Fee
>>
>> Problem Statement:
>>
>> The January 2020 Policy Experience Report highlighted that the existing
>> language in Section 4.2.1.2 “Annual Renewal” references fees. Fees are
>> not considered a member qualification criteria. Since fees aren’t
>> referenced elsewhere in community policy, the wording was reviewed by
>> the PEG.
>>
>> Policy Statement:
>>
>> Given that the Registration Services Agreement (RSA) already contains
>> language regarding fees, the PEG recommends removing the last two
>> sentences referencing from Section 4.2.1.2. The intent of the current
>> wording is accomplished by the existing RSA.
>>
>> Current Policy (12 Aug 2020)
>>
>> 4.2.1.2. Annual Renewal
>>
>> An annual fee for registered space is due by the anniversary date of the
>> ISP’s first allocation from ARIN. ISPs should take care to ensure that
>> their annual renewal payment is made by their anniversary due date in
>> accordance with the Registration Services Agreement. If not paid by the
>> anniversary date, the address space may be revoked. Please review the
>> Annual Renewal/Maintenance Fees Page for more details.
>>
>> Proposed Policy
>>
>> 4.2.1.2. Annual Renewal
>>
>> An annual fee for registered space is due by the anniversary date of the
>> ISP’s first allocation from ARIN. ISPs should take care to ensure that
>> their annual renewal payment is made by their anniversary due date in
>> accordance with the Registration Services Agreement.
>>
>> Timetable for Implementation: Immediate
>>
>> Comments:
>>
>> The AC’s understanding is that community policy should not include
>> language referring to fees, as such language is already present in the
>> Registration Services Agreement (RSA). Registration Services has
>> informed us that “Section 4.2.1.2. contains language detailing fee due
>> dates, encouraging on-time payments, and mentions potential revocations.
>> It also contains a reference to web documentation that has evolved
>> significantly since this policy was implemented, and may continue to do
>> so. Essentially the entire section is made of language that is already
>> in the Registration Services Agreement, and is generally fee-focused,
>> making it outside normal scope for Internet number resource policy.”
>>
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>
>
>
> --
> ===
> David Farmer   Email:far...@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription 

Re: [arin-ppml] Draft Policy ARIN-2020-8: Clarify and Update 4.2.1.2 Annual Renewal Fee

[David Farmer via ARIN-PPML]

I believe Section 4.2.1.2 should be completely removed.

The issues of Annual Renewal is not exclusive to IPv4 or to ISPs, for that
matter, and therefore belongs somewhere else, maybe someplace in Sections 1
or 2.  I also note that the term RSA is used in several locations and is
not defined.  Therefore I suggest we add a new definition to Section 2, as
follows;

2.X Registration Services Agreement (RSA)

All resources allocated by ARIN through the included policies are subject
to a Registration Services Agreement (RSA) between ARIN and the resource
holder. This agreement includes the ability and the terms under
which resources are revoked, including the lack of payment of annual fees.


This definition clarifies the relationship between ARIN's Policies and the
RSA agreement, additionally calling out the existence of fees and that
resources are revoked through the terms of the RSA.

Thanks

On Tue, Aug 25, 2020 at 1:41 PM ARIN  wrote:
...

> Draft Policy ARIN-2020-8: Clarify and Update 4.2.1.2 Annual Renewal Fee
>
> Problem Statement:
>
> The January 2020 Policy Experience Report highlighted that the existing
> language in Section 4.2.1.2 “Annual Renewal” references fees. Fees are
> not considered a member qualification criteria. Since fees aren’t
> referenced elsewhere in community policy, the wording was reviewed by
> the PEG.
>
> Policy Statement:
>
> Given that the Registration Services Agreement (RSA) already contains
> language regarding fees, the PEG recommends removing the last two
> sentences referencing from Section 4.2.1.2. The intent of the current
> wording is accomplished by the existing RSA.
>
> Current Policy (12 Aug 2020)
>
> 4.2.1.2. Annual Renewal
>
> An annual fee for registered space is due by the anniversary date of the
> ISP’s first allocation from ARIN. ISPs should take care to ensure that
> their annual renewal payment is made by their anniversary due date in
> accordance with the Registration Services Agreement. If not paid by the
> anniversary date, the address space may be revoked. Please review the
> Annual Renewal/Maintenance Fees Page for more details.
>
> Proposed Policy
>
> 4.2.1.2. Annual Renewal
>
> An annual fee for registered space is due by the anniversary date of the
> ISP’s first allocation from ARIN. ISPs should take care to ensure that
> their annual renewal payment is made by their anniversary due date in
> accordance with the Registration Services Agreement.
>
> Timetable for Implementation: Immediate
>
> Comments:
>
> The AC’s understanding is that community policy should not include
> language referring to fees, as such language is already present in the
> Registration Services Agreement (RSA). Registration Services has
> informed us that “Section 4.2.1.2. contains language detailing fee due
> dates, encouraging on-time payments, and mentions potential revocations.
> It also contains a reference to web documentation that has evolved
> significantly since this policy was implemented, and may continue to do
> so. Essentially the entire section is made of language that is already
> in the Registration Services Agreement, and is generally fee-focused,
> making it outside normal scope for Internet number resource policy.”
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of OrganizIt reaations Removed from Waitlist by Implementation of ARIN-2019-16

[David Farmer via ARIN-PPML]

Mike,

I appreciate you providing a clear argument. You are saying that the whole
concept of limiting access to the waiting list based on total holdings in
2019-16 is unfair. While I'm not sure I agree, I think this is a
valid question for the community to discuss.

However, many others seem to be claiming that there are fairness issues
with how 2019-16 implemented, but not with the policy itself, in my mind I
don't see how that argument holds water.

Thanks

On Mon, Jul 20, 2020 at 10:34 AM Mike Burns  wrote:

> Hi David,
>
>
>
> What was not arbitrary was the choice to impose any limit whatsoever on
> the amount of holdings an organization can  have while retaining access to
> the free pool via the waiting list.
>
>
>
> That was a shining line crossed, no matter the (acknowledged)
> arbitrariness of the size selected.
>
>
>
> As a community we should have been able to discuss the radical step away
> from treating all organizations equally when it comes to free pool access.
> I can remember discussions in the past which included large companies
> jealous of their rights in the context of making transfers needs-free below
> a certain size.  They argued, convincingly I thought, that continuing to
> impose the needs-test on large blocks while exempting small blocks was an
> impermissible relegation of our community members into different classes.
>
>
>
> Would it be permissible if the community decided that organizations with a
> market cap over $100 million are not allowed to purchase IPv4 blocks?
>
> By the logic employed in the holdings-cap on waiting-list access, I don’t
> see any reason why it wouldn’t be permissible.
>
> We are deciding that small holders should get access and large holders
> should not get access to the free pool, what is the difference between the
> free pool and the transfer pool?  Shouldn’t the same reasons we advance
> small holders obtain?
>
>
>
> Other RIRs decided that new entrants should stand in line before existing
> organizations, based on the logic that it was the older organizations who
> are more responsible for creating the scarcity environment, and many
> received their addresses before they had to pay for them, so in recognition
> of the comparably greater hardship faced by new entrants, the proper
> treatment was to prefer new entrants.
>
>
>
> Some in this community may feel that way, or they may have other reasons
> to prefer smaller companies over larger companies.  We should have had a
> discussion and a vote on this singular issue instead of crossing this line
> the way it was crossed, in the Advisory Council deliberations.
>
>
>
> I do understand that large holders pay more fees, that is not an issue for
> me, it’s the denial of access to certain pools that bothers me.
>
>
>
> What troubles me is the concept that holders below /18 are “innocent” and
> those over, by inference, are less so. The cap was implemented in the wake
> of a particular fraud on the waiting list that was not a function of the
> size of the fraudster’s holdings but fraud on the justification
> attestations.  I am not clear on how the cap on holdings was meant to
> address that particular fraud.
>
>
>
> I do support the policy as a step forward but I think there should be no
> cap on holdings because then access to the free pool is no longer impartial.
>
> It’s partial to small holders.
>
>
>
> Regards,
> Mike
>
>
>
>
>
>
>
>
>
> *From:* ARIN-PPML  *On Behalf Of *David
> Farmer via ARIN-PPML
> *Sent:* Monday, July 20, 2020 10:29 AM
> *To:* Tom Pruitt 
> *Cc:* arin-ppml@arin.net
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of
> OrganizIt reaations Removed from Waitlist by Implementation of ARIN-2019-16
>
>
>
> I have to disagree, the implementation of 2019-16 was fair and impartial.
> There was a general criterion that was applied, it wasn't overly specific,
> such that it only targeted a single or small group of specific
> organizations. Yes, the selection of /20 was mostly arbitrary, but any
> number picked would have been mostly arbitrary. The /18 that this policy
> proposes is mostly arbitrary as well. The specific numbers are a judgment
> call, both in 2019-16 and this policy. Nevertheless, innocent organizations
> were impacted by the implementation of 2019-16, and that is regrettable,
> unfortunate, and frankly, it sucks, but that doesn't me it was unfair.
>
> Further, the alternative implementation, that you propose would have been
> unfair because the organizations with a /20 or less of total holdings, but
> requesting more than a /22, would qualify under the policy in 2019-16 if
> they simply reduced their request. Therefore, 

Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of OrganizIt reaations Removed from Waitlist by Implementation of ARIN-2019-16

[David Farmer via ARIN-PPML]

I have to disagree, the implementation of 2019-16 was fair and impartial.
There was a general criterion that was applied, it wasn't overly specific,
such that it only targeted a single or small group of specific
organizations. Yes, the selection of /20 was mostly arbitrary, but any
number picked would have been mostly arbitrary. The /18 that this policy
proposes is mostly arbitrary as well. The specific numbers are a judgment
call, both in 2019-16 and this policy. Nevertheless, innocent organizations
were impacted by the implementation of 2019-16, and that is regrettable,
unfortunate, and frankly, it sucks, but that doesn't me it was unfair.

Further, the alternative implementation, that you propose would have been
unfair because the organizations with a /20 or less of total holdings, but
requesting more than a /22, would qualify under the policy in 2019-16 if
they simply reduced their request. Therefore, requiring them to be removed
from the waiting list and to reapply would have been unnecessarily
bureaucratic and petty, with the only effect being that they lost their
place on the waiting list. Allowing these entities to reduce their request
seems an eminently fair way do deal with that situation.

Personally, I like and support the concept of mitigating at least some of
the impact on innocent organizations by allowing those with up to and
including a /18 of total holdings back on the list for up to a /22. I'll
note that this specific idea didn't come up during the discussions leading
up to 2019-16 or immediately following the implementation of it.  However,
while I support mitigating the effects of 2019-16 on several innocent
organizations, I most strenuously object to referring to the implementation
of 2019-16 as unfair. The implementation of 2019-16 was both fair and
impartial, even though the impact on some organizations was undesirable, it
was nevertheless fair.

Thanks.

On Fri, Jul 17, 2020 at 3:34 PM Tom Pruitt  wrote:

> The organizations this draft policy would affect  had qualified for space
> before 2019-16 (limiting space to a /20 and limiting a max request to a
> /22) was implemented.  The implementation of the policy removed the
> organizations that had over a /20, but allowed organizations with less than
> that who wanted more than a /22 to adjust their request and remain on the
> list.  If all organizations who didn't fit the new criteria  with their
> existing requests were removed then it would have been applied fairly and
> equal, but that isn't what happened.
>
> This proposal actually equalizes the implementation of 2019-16.
>
>
> Yes the problem is the lack of IPv6 deployment, I don't think anyone can
> argue that.
>
> Thanks,
> Tom Pruitt
> Network Engineer
> Stratus Networks
>
> This e-mail, and any files transmitted with it are the property of Stratus
> Networks, Inc. and/or its affiliates, are confidential, and are intended
> solely for the use of the individual or entity to whom this e-mail is
> addressed. If you are not one of the named recipient(s) or otherwise have
> reason to believe that you have received this message in error, please
> notify the sender at 309-408-8704 and delete this message immediately from
> your computer. Any other use, retention, dissemination, forwarding,
> printing, or copying of this e-mail is strictly prohibited
>
> -Original Message-
> From: ARIN-PPML  On Behalf Of Fernando
> Frediani
> Sent: Friday, July 17, 2020 11:01 AM
> To: arin-ppml@arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of
> Organizations Removed from Waitlist by Implementation of ARIN-2019-16
>
> What is the justification to give organization who already have some
> reasonable space to work with, more space in current times ?
>
> Everybody is suffering from the same problem of IPv4 scarcity and that
> affects all equally. If we have already a policy that limits on /20 it is
> for a reason, a fair reason by the way. So why are we going to bend it in
> this case in the other direction ?
> I see this type of proposal privileging just a few rather than been
> equalized to all others.
>
> Therefore I keep opposed to it.
>
> Fernando
>
> On 17/07/2020 12:24, Steven Ryerse via ARIN-PPML wrote:
> > +1
> >
> >
> > Steven Ryerse
> > President
> >
> > srye...@eclipse-networks.com | C: 770.656.1460
> > 100 Ashford Center North | Suite 110 | Atlanta, Georgia 30338
> >
> >
> >
> >
> >
> > -Original Message-
> > From: ARIN-PPML  On Behalf Of Mike Burns
> > Sent: Friday, July 17, 2020 10:59 AM
> > To: hostmas...@uneedus.com; arin-ppml@arin.net
> > Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of
> > Organizations Removed from Waitlist by Implementation of ARIN-2019-16
> >
> > I support the policy as written and I do not believe we should
> prioritize small holders over large holders.
> > Large holders pay higher fees but I don't see the rationale behind
> favoring small  holders on the wait list.
> > All holders should be on