Re: [arin-ppml] Transferring Waiting List Space - Feedback Requested
Re: Preventing waitlist recipients from transferring their space indefinitely (instead of only a five-year lockout) The point of this change seems to be to disincentivize organizations from joining the waitlist simply to acquire space they can later sell for a profit. That makes sense. But it helps to consider how changing the lockout period affects other incentives. If an organization acquires space from the waitlist and no longer needs it (assume the five-year period has elapsed), that org has a strong financial incentive to sell the space. For example, if the market price per address at that time is, say, $37, a /22 might be worth ~$38,000. (Not making any statements about market price; just picking an arbitrary price for the sake of this hypothetical.) Selling that space would put it in the hands of another entity that would actually use it, improving the efficient allocation of space. On the other hand, if the organization that acquired waitlist space no longer needs it, and ARIN restricts the org indefinitely from transferring that space to another entity, then it would cost that org only $500/year to hold onto it instead of returning it to ARIN. The organization might think, "Well, I don't currently need this space. But it's possible I might need it in the future. Better to pay $500/year and keep it just in case rather than return it to ARIN and go to the back of the waitlist if I need IPv4 space in the future." (Invitation to supplement/correct my fee assumptions here) In other words, permitting resale after some period might promote the more efficient use of space. What is the right resale lockout period to promote the efficient use of space while discouraging entities from joining the waitlist solely to get space they can resell? Hard to say. But I don't think an indefinite lockout period adequately balances those competing incentives. Nick On Tue, Nov 15, 2022 at 2:30 PM Brian Jones wrote: > Alison, > As I stated at the ARIN50 meeting, in light of the report John Sweeting > gave ( > https://www.arin.net/participate/meetings/ARIN50/materials/1020_policyimplementation.pdf) > I would be in favor of reducing the minimum allocation size to a /24. I am > not necessarily in favor of lowering the maximum holdings for eligibility. > I would not favor eliminating the transfer of Waitlist blocks. I think five > years serves the purpose for that. > > > Brian Jones > Virginia Tech > ARIN Advisory Council > > > > On Nov 14, 2022, at 4:42 PM, WOOD Alison * DAS > 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. > > > ___ > 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.
Re: [arin-ppml] Revised - Draft Policy ARIN-2022-8: Streamlining Section 11 Policy Language
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
