<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Just a reminder that I’d love to get comments on any and all aspects of this list by Friday (tomorrow) night.</div><div class=""><br class=""></div><div class="">The AC has a call next Thursday (a week from today) and I would like plenty of time to collate them into a summary for discussion.</div><div class=""><br class=""></div><div class="">Regards,</div><div class=""><br class=""></div><div class="">-r</div><div class=""><br class=""></div><div class="">PS: I am sure it was fairly clear from the context, but I should have mentioned last week that the use of first person pronouns such as “I” and “We” in these comments reflects the opinions of individual reviewers not the AC.</div><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 7, 2019, at 1:34 PM, Rob Seastrom <<a href="mailto:rs-lists@seastrom.com" class="">rs-lists@seastrom.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><div style="margin: 0.4em 0px 0.5em; font-family: sans-serif; font-size: 12.699999809265137px;" class="">Dear Colleagues,</div><div style="margin: 0.4em 0px 0.5em; font-family: sans-serif; font-size: 12.699999809265137px;" class="">Starting immediately after our annual meeting in late January, the ARIN AC began curating a list of possible policy actions to take in response to the Board's suspension of the waiting list policy. We would like to share that list of possible actions and comments with the Community. While the attached list of actions is not a policy proposal we hope that it will stimulate constructive discussion regarding ARIN-2019-2, and possibly even lead to submission of additional or supplementary policy proposals. Current discussions have already covered many of the topics that we raised.</div><div style="margin: 0.4em 0px 0.5em; font-family: sans-serif; font-size: 12.699999809265137px;" class="">I have incorporated feedback on 2019-2 on PPML up to 1315 EST today.</div><div style="margin: 0.4em 0px 0.5em; font-family: sans-serif; font-size: 12.699999809265137px;" class="">I'll be incorporating feedback on this thread into our working documents on Friday, March 15th, so please expedite your thoughtful responses.</div><div style="margin: 0.4em 0px 0.5em; font-family: sans-serif; font-size: 12.699999809265137px;" class="">Anticipating at least one complaint (and suffering from lack of confidence that PPML won’t strip the RTF and render something entirely incomprehensible) please accept my apologies for non-pure-ASCII email and accept my pointer to this document in PDF format at <a href="https://technotes.seastrom.com/assets/2019-03-07-NRPM-4-1-8-Policy-Actions/2019-03-07-NRPM-4-1-8-Policy-Actions.pdf" class="">https://technotes.seastrom.com/assets/2019-03-07-NRPM-4-1-8-Policy-Actions/2019-03-07-NRPM-4-1-8-Policy-Actions.pdf</a></div><div style="margin: 0.4em 0px 0.5em; font-family: sans-serif; font-size: 12.699999809265137px;" class="">Kind regards,</div><div style="margin: 0.4em 0px 0.5em; font-family: sans-serif; font-size: 12.699999809265137px;" class="">-r</div></div><div style="margin: 0.4em 0px 0.5em; font-family: sans-serif; font-size: 12.699999809265137px;" class=""><br class=""></div><div class=""><h2 style="font-family: -webkit-standard;" class="">Problem Space</h2><ol style="font-family: -webkit-standard;" class=""><li class="">Returned and/or reclaimed number resources, are stranded at ARIN absent policy enabling their distribution. These resources are of two primary sources: organizations quitclaiming (voluntarily surrendering) prefixes and number resources that are revoked due to non-compliance with the RSA (primarily non-payment of fees).</li><li class="">This pool must be drained in an orderly fashion. This must be sustainable to provide a buffer/queue system to manage any future free pools, with an orderly in/out sequence. At some point the demand vs return rate of IPv4 space will be such that we transition rapidly back and forth between having an ephemeral free pool and a waiting list and it is important to consider fair and impartial issue of number resources under that circumstance.</li><li class="">A non-trivial fraction of the space issued under the 4.1.8 waitlist policy is "flipped" as soon as it becomes eligible, after the current hold down of 1 year post-issue. This problem seems exacerbated in larger allocations (shorter prefixes). Conversations in the wake of 4.1.8’s suspension (both private and public) suggest that the now-suspended waiting list policy is not aligned with its original intent.</li><li class="">Policy action taken could reduce the incentive for fraudulent applications or making misrepresentations to registration services (which have existed since time immemorial). The observed flipping pattern raises serious concerns about the legitimacy of the "documented need" attached to some applications.</li><li class="">The ARIN community established the waiting list intentionally without many controls with the expectation that we would need to adjust it over time with the benefit of experience and observation.</li><li class="">While by no means a universal sentiment, several people have raised the issue of serving organizations that are unable to otherwise participate in the transfer market in a meaningful way. This implies certain NGOs, smaller organizations, new entrants, etc.</li></ol><p style="font-family: -webkit-standard;" class="">Discussion:</p><ul style="font-family: -webkit-standard;" class=""><li class="">While I generally agree with the problem statements... I'm not sure they are all problems that the wait-list policy update needs to "solve". Specifically problem 6. While I think its nice that the wait-list is available to organizations which may not have the funds available to get a block on the market. The “economist” in me says that if that an organization really needs IPv4 addressing then they will put their resources (dollars) to work to find a block (even via transfer). If they don't really "need" a block, they will likely use (borrow/lease) someone else's or substitute NAT. And that might just be OK.</li><li class="">While all things being equal, I could potentially agree, the reality is that these blocks aren't on the transfer market for whatever reason and I don't think ARIN should be in the business of providing opportunities for others to monetize them (isn't that the whole issue that caused the policy suspension in the first place?). Thus, I think that the class most in need and least likely to look at monetization is, in fact, the groups identified in item 6 above.</li><li class="">a meta-issue to consider is whether there should be any difference between IPv4 issuance via waiting list and IPv4 issuance via NRPM 4.2/4.3 when resources are available; i.e. should NRPM 4.1.8 simply read that ARIN will maintain an ordered waiting list when resources are not available and fullfil in that order once space becomes available – and then simplified criteria for how a party receives IP space is put in NRPM 4.2 and NRPM 4.3. If this is not the strategy taken, then a party put on the waiting list last week and then receiving space today (due to new influx of resources) will be treated quite differently under a revised 4.1.8 policy than parties applying and issued space from the replenished pool tomorrow. Such oscillations are nethier predictable nor particularly equitable, and yet will be a reality (particular if the resources issued under revised waiting list policy are limited in size.) <i class="">This is another way of characterizing problem #2 above - differences between waiting list policy and "regular" issuance only increase the inequity and thus morst of the policy options on the menu below probablem shouldn't indicate they address statement #2... </i></li><li class="">An alternative approach to avoid oscillation would be to make the gate into waiting list behavior a one-way gate. Once the waiting list is activated, even if the queue is drained, all new applications would be placed on the waiting list and immediately filled if possible. </li><li class=""> Certainly a possibility (<i class="">one way gate... all new applications would be placed on the waiting list and immediately filled if possible.) </i>for addressing the issue. </li><li class="">I could get behind part of the fix eliminating the possibility of oscillation by the wait list becoming the universal front door; everyone in on the wait list all the time and just the wait is short when resources are plentiful.</li><li class="">It is not reasonable to ask the Community to weigh in policies based on allegations of fraud without data from Registration Services ( + 3)</li><li class="">Summary data posted to PPML in Message-ID: <<a href="mailto:98C1F5A7-0584-4996-9298-B92594B673E0@arin.net" class="">98C1F5A7-0584-4996-9298-B92594B673E0@arin.net</a>></li><li class="">Sweeting's Policy Experience Report from ARIN 42 in Vancouveris available in the following locations:<ul class=""><li class="">Transcript: <a data-cke-saved-href="https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcript.html#anchor_5" href="https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcript.html#anchor_5" alt="https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcript.html#anchor_5" title="https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcript.html#anchor_5" class="">https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcript.html#anchor_5</a> </li><li class="">Youtube: <a data-cke-saved-href="https://www.youtube.com/watch?v=MJHgs4wWO58" href="https://www.youtube.com/watch?v=MJHgs4wWO58" alt="https://www.youtube.com/watch?v=MJHgs4wWO58" title="https://www.youtube.com/watch?v=MJHgs4wWO58" class="">https://www.youtube.com/watch?v=MJHgs4wWO58</a></li><li class="">Presentation: <a data-cke-saved-href="https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/sweeting-policy.pdf" href="https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/sweeting-policy.pdf" alt="https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/sweeting-policy.pdf" title="https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/sweeting-policy.pdf" class="">https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/sweeting-policy.pdf</a> </li></ul></li><li class=""><br class=""></li></ul><p style="font-family: -webkit-standard;" class=""><br class=""><br class=""><br class=""></p><h2 style="font-family: -webkit-standard;" class="">Potential Policy Actions</h2><p style="font-family: -webkit-standard;" class="">For brevity, the reclaimed or returned IPv4 resources received by ARIN currently handled by the waitlist is referred to below as “4.1.8 space”.<br class=""><br class=""></p><p style="font-family: -webkit-standard;" class=""><br class=""></p><p style="font-family: -webkit-standard;" class=""><br class=""></p><h3 style="font-family: -webkit-standard;" class="">Policy Menu for discussion</h3><ol style="font-family: -webkit-standard; list-style-type: upper-alpha;" class=""><li class="">Regardless of any other policy options pursued for 4.1.8 space, we will need to determine the fate of the current wait list entries. Do we use the new waitlist policy as a forcing function (i.e. if there is a change in maximum prefix size do we trim all existing justifications to be limited as under the new policy), or do we grandfather prefix length, grants per org, etc under the policy in effect as of the suspension date of the 4.1.8 policy (Wednesday, 16 January 2019) or the publication of the Board minutes (7 February 2019)? Other cutoff dates seem less fair.<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2, 5 plus overlay on particular policy actions</li><li class="">Does not address: overlay on particular policy actions</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class="">If "new policy applies to all unfilled requests". If an org takes a haircut on what they can get from the waiting list, what happens to the remainder? Do they lose it? Should they be able to turn it into a preapproval for 8.3? We believe that there are folks on the list *right now*, in the larger allocation space, who are likely to "flip" space. Is allowing them to keep their place in line fair?</li><li class="">Agreed. Given some existing applications could be fraudsters, the new policy possibly should apply to existing applicants; OTOH new listers are the only ones who knew the rules were changing. We should allow folks current on the list who do not wish to participate in the new policy (fees, additional paperwork, whatever) the option to delist without issue. Given some of the options (eg, only one chance, no if you have other resources, etc) we would be forcing many off the list regardless.</li><li class="">reducing the size allocated will likely reduce the fraud potential. I feel that those on the list should be given the opportunity to keep their place on the list (assuming we keep the list, but their max size would be reduced to the new agreed max size.</li><li class="">Tackling this first seems cart before the horse to me. I think that what we decide on the other topics (how the policy actually changes) should inform what we determine will be most fair to those on the existing waiting list. In terms of if we reduce the maximum prefix size, then I would suggest that perhaps we could pursue a compromise where those on the waiting list prior to suspension aren't completely grandfathered, but are permitted a somewhat (perhaps 2 bits or x4) larger maximum prefix size than the new limit. (e.g. if we take the new limit to /24, those grandfathered would be eligible up to a /22).</li><li class="">It is a meta topic; these are only ordinal to be managable, feel free to skip consideration until we assess the rest, but IMO that goes against the grain of the desire to think things through well before discussing with the community. As far as prefix size, I'm 100% against adding one-off bit-math exception complexity. Simple grandfather or not is a reasonable discussion to have but making a temporary new rule category is a bad idea.</li></ol></li></ol></li><li class="">4.1.8 space to be held in a “replenishment pool” for 4.4/4.10 (or similar)<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2, 3, 5</li><li class="">Does not address: 6</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class="">Depending upon the expansion of “4.4/4.10 (or similar)” may or may not address item 4. Highminded and while “orderly” (2) I think would result in very little payout, eventually not addressing the pile (1). I doubt we’ll see community support.</li><li class="">Unlikely to see community support; also sends wrong message about the future of IPv4.</li><li class="">I'd suggest that using these blocks for 4.4/4.10 is possibly providing a way for ARIN to serve the "small" members of the community by creating a larger pool of small blocks that could be used for these new entrants. Is it a lot of space, no, but you can do a lot with a /24.</li><li class="">I believe that this would create new incentives for fraud in the 4.10 space which is already strongly incentivized towards fraud (almost with encouragement from the ARIN staff via a very liberal interpretation of "transition").</li></ol></li></ol></li><li class="">Distribute 4.1.8 space with a one time issuance surcharge attached - "the board should consider implementing a fee structure."<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2, 5</li><li class="">Does not address: 6</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class="">Elevated fee for getting space from the waiting list. Possibly more fair than putting it on the market. Definitely better optics. But if the target recipients are organizations that are otherwise unable to participate in the transfer market, then at least some organizations will be priced out.</li><li class="">Possibly address items 3 & 4, but I’m concerned that the fee would have to be <b class="">significant</b>to outweigh the ROI for people already willing to both wait and risk their existing & future relationship with ARIN. Might be useful in combination with other actions.</li><li class="">I think the negatives of this approach for the classs defined in 6 outweigh any possible positives for 1, 2, 5. I do not believe it will do anything for 3, 4 unless the fees are so high as to approach parity with the transfer market. I nominate this one for the considered and rejected bucket.</li></ol></li></ol></li><li class="">Make 4.1.8 space non-transferrable (must return to ARIN).<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2, 3, 5</li><li class="">Does not address: 6</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class="">Does this mean just no 8.3? How about 8.2? Disadvantage - basically makes "off the books" transfers the only way to transfer the space. We have put a lot of effort into making the database right. This creates the problem that we have been trying to avoid.</li><li class="">Given the waiting list isn’t the only path to get v4 I’m not certain the risk of the underground market is very high. Were we back in the times before the transfer market, I would solidly agree. However I don’t think this would gain community support unless it was in combination with other actions. Given that response, whether or not item 4 is addressed seems to be in play.</li><li class="">non-transferable still means people can lease/reallocate. </li><li class="">Let's be clear about this... I believe it should mean (no 8.3) and no (8.4 except in case where would otherwise qualify under 8.2). Perhaps some additional hoops should be added for 8.2/8.2-related 8.4 (possibly restore the resource review and reclamation provisions where 4.1.8 space is involved?) . </li><li class="">I don't see this as not adressing 6. I also think it strongly addresses 4. It might not reduce incentives for fraudulent transfers of space received under this policy, but it does at least reduce the incentives to apply fraudulently in the first place. I would say Addresses: 1, 2, 3, 4, 5, 6 (to varying extents).</li><li class="">The reason I put 'does not address 6' is it does not specifically favor or disfavour.</li><li class="">I agree that the reduction of the incentives to apply and flip will be greatly reduced. I am concerned with M&A transfers as many times, equipment gets moved over and the IPs come along with that. Giving space back that happened to be from the waiting list at some point would impact companies greatly. There is an actual need for that space and not a resource flip for money. Reallocations would be allowed so I see no issues in that regard. This in conjunction with smaller aggs from the waiting list would probably give us the a very good start. </li></ol></li></ol></li><li class="">Longer holddown period for transfer after receiving 4.1.8 space<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2, 5</li><li class="">Does not address: 6</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class="">Could be a disincentive for people who are gaming the system for financial gain. Might just end up turning transfers into LOAs and rentals. In the interests of database accuracy we still need to allow 8.2</li><li class="">I have the same concerns with items 3 & 4 as with policy option for “suggest fees to board”. We have a serious unknown WRT the level of disincentive needed. Might be useful in combination.</li><li class="">I think this is just a less-effective alternative to D. I nominate this one for the considered and rejected bucket on that basis.</li><li class="">If we are talking about 2+ years then I think we'd see an impact as companies would gamble the cost of the IP but I like option D better. </li></ol></li></ol></li><li class="">Only one 4.1.8 application / grant per applicant (no getting back in line/one bite at the apple)<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2, 5, 6</li><li class="">Does not address: 3, 4</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class="">Increases the overhead for milking the system (creating multiple corporate entities, etc) but this may not be as much overhead as we suppose; legitimate businesses spin up operating entities at the drop of a hat. Sends signal about "new entrants". Creates the problem that RIPE NCC has right now - because they did that for their final /8, there are a lot of shell LIRs that were created for the sole purpose of getting the space.</li><li class="">Similar to options for “suggest fees to board” & long holddown”, I think this only moves the line for fraud, and not very far. We should not ignore RIPE’s shell LIR experience and I don’t think their fix would apply for us. I don’t think this is a useful lever in conjunction with other options.</li><li class="">I think this is a high staff impact low fraudster impact mechanism for moving the bar on fraud only slightly. As such, I nominate it for the considered and rejected bucket.</li></ol></li></ol></li><li class="">No 4.1.8 applications for any existing V4 resource holder<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2, 5, 6</li><li class="">Does not address: 3, 4</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class="">Same as “no getting back in line” - creating shell organizations for the purpose of getting space from ARIN. TODO - Get quotes from <a data-cke-saved-href="https://www.delreg.com" href="https://www.delreg.com/" alt="https://www.delreg.com" title="https://www.delreg.com" class="">https://www.delreg.com</a>for fixed and variable costs of setting up a shell corporation and add in the minimum documentation overhead to make a model.</li><li class="">I’m sure I could spend time finding current rates, but here’s 2015 data, that sticks to my “very low” answer <a data-cke-saved-href="https://blog.corpnet.com/fees-incorporating-state-understand-costs-corporation/" href="https://blog.corpnet.com/fees-incorporating-state-understand-costs-corporation/" alt="https://blog.corpnet.com/fees-incorporating-state-understand-costs-corporation/" title="https://blog.corpnet.com/fees-incorporating-state-understand-costs-corporation/" class="">https://blog.corpnet.com/fees-incorporating-state-understand-costs-corporation/</a>. I don’t think the community would support this nor that it would be meaningful in conjunction with other actions. I think this should be demoted to “considered and rejected”.</li><li class="">Last year, I needed to spin up an entity. I hired a service to do all of it beginning to end for $150 and about 15 minutes of filling out web forms. (If I had known what I was doing with the web forms, I probably could have done it in more like 2 minutes).</li><li class="">To me, this is just a more obnoxious form of F and I believe it should suffer the same suggested fate.</li><li class="">FWIW, APNIC is considering abolishment of their waiting list. Since they had a soft-landing policy, they are considering reserving reclaimed resources for new entrants only, similar to this option: <a data-cke-saved-href="https://www.apnic.net/community/policy/proposals/prop-129" href="https://www.apnic.net/community/policy/proposals/prop-129" alt="https://www.apnic.net/community/policy/proposals/prop-129" title="https://www.apnic.net/community/policy/proposals/prop-129" class="">https://www.apnic.net/community/policy/proposals/prop-129</a>.</li></ol></li></ol></li><li class="">Additional officer attestation at time of being placed on waiting list (or at time of issuance? or both?), under penalty of perjury of lack of relationship to any other organization that is on the waiting list.<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2, 4</li><li class="">Does not address: 3, 5, 6</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class="">This is out of the purview of the AC as it does not relate directly to number policy however it may be part of our guidance to the Board that they discuss such a measure with Counsel. </li><li class="">I don’t know how much of the fraud this would actual cut into, being a reference to other entities on the list.</li><li class="">Rather than reference other entities on the list, I would suggest it reference other entities which have received 4.1.8 waiting list approval and/or space.</li><li class="">It might not reduce fraud by much (or it might reduce it a lot). However, it seems very low staff overhead with good potential. I think combined with other options, notably {D, I.(J, K, or L)}</li><li class="">My understanding is that formal attestations increase the hooks for hanging fraud-related complaints on should they be egregious enough to send to LE etc, so it may be inefficient at cutting into fraud yet still desirable.</li></ol></li></ol></li><li class="">Reduce maximum allocation for 4.1.8 space (general action - subsequent are more specific)<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2, 4, 5, 6</li><li class="">Does not address:</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class=""><br class=""><ol style="list-style-type: circle;" class=""><li class="">Advantages<ol style="list-style-type: square;" class=""><li class="">Increases the number of organizations that can be served.</li><li class="">Lessens the impact of "loophole applications" that make it through</li><li class="">The necessity of repeated transactions (grant events) in order to amass a significant amount of space increases the paper trail for detecting undesirable behavior.</li></ol></li><li class="">Disadvantages<ol style="list-style-type: square;" class=""><li class="">Some otherwise deserving organizations will not be able to get all the space they can justify regardless of how long they are willing to wait.</li><li class="">More grant events (i.e. more number blocks being handed out) and attendant shortening of waiting period may increase incidence of loophole or fraudulent applications.</li><li class="">Increased workload on Registration Services (operational issue outside of the scope of our policy discussion)</li></ol></li></ol></li><li class="">I think this is a required piece of any solution. Reduces but wouldn’t eliminate 3</li><li class="">I also think this is a required part of any solution as long as the solution isn't "transfer at market price"</li><li class="">Agree this is the single best action we can take and is likely improved by combining with other action(s) (notably D)</li><li class="">Per item 6, I'm less concerned about deserving organizations getting limited space.</li><li class="">While it does shorten the "waiting period", it wouldn't remove the 3 month hold-down in the policy (unless we did so deliberately). We could combine with (E) to further address the "attendant shortening" issue.</li><li class="">Agree with the comments above that this needs to be part of the solution but not the only solution</li></ol></li></ol></li><li class="">Reduce maximum 4.1.8 allocations to /24 (or more likely "minimum allocation as elsewhere in policy")<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2, 3, 4, 5, 6</li><li class="">Does not address: n/a</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class=""><br class=""><ol style="list-style-type: circle;" class=""><li class="">Advantages<ol style="list-style-type: square;" class=""><li class="">Serves the most number of organizations</li><li class="">Maximally reduces fraud incentive, particularly when combined with "one grant per applicant"</li><li class="">Maximizes grant events (see I.c.c above) for detecting activity by bad actors</li><li class="">RIPE is about to do it (see RIPE-2019-02:Reducing IPv4 Allocations to a /24) <a data-cke-saved-href="https://www.ripe.net/participate/policies/proposals/2019-02" href="https://www.ripe.net/participate/policies/proposals/2019-02" alt="https://www.ripe.net/participate/policies/proposals/2019-02" title="https://www.ripe.net/participate/policies/proposals/2019-02" class="">https://www.ripe.net/participate/policies/proposals/2019-02</a><a data-cke-saved-href="https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-February/012623.html" href="https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-February/012623.html" alt="https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-February/012623.html" title="https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-February/012623.html" class="">https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-February/012623.html</a></li></ol></li><li class="">Disadvantages<ol style="list-style-type: square;" class=""><li class="">Maximizes the number of organizations that could justify more yet are shortchanged</li></ol></li></ol></li><li class="">I think this is the biggest bang for our buck, solo or in combination. This and “recommend fees” and [another option] would be best IMO.</li><li class="">If we are going to reduce to a /24 why not just put these in the 4.10 pool, then we give people a carrot to also do the right thing and get some v6 to bootstrap their organization</li><li class="">Re 4.10 pool, That's not the original intent of 4.10, though it is how staff is currently advertising it. IMHO, we should move away from 4.10 being used for v4 for people who joined the v6 club and go back to actually requiring 4.10 space be used for actual transition purposes.</li><li class="">I sort of agree but I feel that it might be more bang than is needed and that the downside to any but the smallest of the small may exceed the benefit.</li><li class="">This or K in combination with D would be my suggestion as well. I'm on the fence for /24 vs /22 as there are certainly pluses and minus to each approach. Also making specified transfered not able to use wait list space will really disincentivize the flippers. </li></ol></li></ol></li><li class="">Reduce maximum 4.1.8 allocations to /22<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2, 5</li><li class="">Does not address: 3, 4, 6</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class=""><br class=""><ol style="list-style-type: circle;" class=""><li class="">Still substantially no questionable applications at this level <b class="">under today's policies</b></li><li class="">Able to serve a greater diversity of organizations that could justify more space than a /24 (think WISP, boutique cloud providers).</li><li class="">RIPE has had documented experience with a /22 policy along with negligible amounts of documentation (pretty much a gimme for any new LIR). Note that ARIN != RIPE and we are not discussing getting rid of needs basis for this. Whether the RIPE experience counts as a success story is likely in the eyes of the beholder, but we have something to calibrate our expectations against.</li></ol></li><li class="">I think the RIPE experience pushes away from this, and that the line for fraud would just move here as a /22 is still highly valuable.</li><li class=""> /22 seems like a good place to start the discussion on a new max block size</li><li class="">I agree with the /22.</li><li class="">Will the fraud line move here? Possibly, but the incentive to overhead ratio changes dramatically (1 application + 1 year = /16 = roughly $1,310,570 ($20/address - $150 ARIN fee) vs. 64 Entity spinups + 64 applications + 1 year = badly fragmented /16 equivalent = roughly $1,301,120 ($20/address - 64*$150 ARIN fees)</li><li class="">I believe this combined with D is probably our best choice.</li><li class="">Increased number of transactions going past Registration Services is good for discerning patterns.</li><li class="">if increased transactions are good, then isn't that an even better argument for (J) and moving to /24s?</li><li class="">I'm having trouble squaring that 'overhead' and your comments under (G) - 64 orgs per your experience would be under 10k so the profit is barely touched (1.29M vs 1.31M). I have <b class="">never</b>seen shell creation/shelf activation as a significant barrier; while they seem weird to us as engineers, criminal enterprises are very very used to them being a required part of doing illegal business.</li><li class="">I believe this or J in combination with D is the best choice. I could probably be convinced either way on /24 or /22. </li><li class="">RIPE's experience has been a train wreck and organizations have plundered the /22 space to where certain recipients have amassed in the low hundreds of /22s each.</li><li class="">Not fair to equate RIPE's experience with /22s. There is no justification requirement in RIPE. Form a corp, have a presence in the RIPE region, and you get a /22 whether you can justify it or not.</li></ol></li></ol></li><li class="">Reduce maximum 4.1.8 allocations to /21 or /20<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2, 5</li><li class="">Does not address: 3, 4, 6</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class="">:<ol style="list-style-type: circle;" class=""><li class="">Advantages<ol style="list-style-type: square;" class=""><li class="">Still substantially no questionable applications at this level <b class="">under today's policies</b></li></ol></li><li class="">Disadvantages<ol style="list-style-type: square;" class=""><li class="">at 8 or 16x the payout per transaction, a tempting place for attempted loopholing to land.</li><li class="">Nevertheless, a loophole /20 consumes 1/16 the resources of a loophole /16 (most of these are in the /17-/18 range but still...)</li></ol></li></ol></li><li class=""> I don’t think this level of incrementalism will buy us much of anything.</li><li class="">/22 seems like a good place to start the discussion on a new max block size</li><li class="">I don't believe this gains us anything as this isn't small enough. Smaller allocations serve more members of the ARIN community. I'm more comfortable with a /22 or /24</li></ol></li></ol></li></ol><p style="font-family: -webkit-standard;" class=""><br class=""><br class=""></p><h3 style="font-family: -webkit-standard;" class="">Policy options considered and rejected</h3><ol style="font-family: -webkit-standard; list-style-type: upper-alpha;" class=""><li class="">No longer reissue 4.1.8 space (i.e. continue waiting list suspension indefinitely)<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 3, 4, 5</li><li class="">Does not address: 1, 2, 6</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class="">Functionally equivalent to eliminating the waiting list. Unlikely to get community support and with the (actually a little surprising) velocity of space reclamation ARIN will eventually end up with a non-trivial amount of space.</li><li class="">firmly agreed.</li><li class="">I wouldn't reject this one so quickly; it doesn't make any sense if we sit on the space, but if it could be redeployed (my favorite option: use as supply for crit infra allocations), this could be a viable path.</li><li class="">The counterpoint to that preference is that the current CI pool will last much longer than any of us want IPv4 to continue to be CI.</li></ol></li></ol></li><li class="">ARIN Stops accepting applications for 4.1.8 space, only supporting transfer (8.x), critical infrastructure (4.4), or IPv6 transition (4.10) policies<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 3, 4, 5</li><li class="">Does not address: 1, 2, 6</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class="">Closes down the entry side of the policy, not the issuance side. Net result ends up being the same - can't have requests for the space, so it will pile up.</li><li class="">firmly agreed.</li><li class="">This is smilar to the B above, so why is this specifically rejected it seems similar.</li></ol></li></ol></li><li class="">Prioritize "not for profit" organizations’ applications for 4.1.8 space, potentially to the exclusion of all others.<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2, 5, 6</li><li class="">Does not address: 3, 4</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class="">such status is merely an artifact of national tax laws; they say nothing about budgets or size.</li><li class="">agreed; would include superPACs in the US.</li><li class="">I think there is value in considering this as an option for discussion. I suspect it doesn't go anywhere, but I think its worth while.</li><li class="">Could limit it to "organizations eligible to receive tax deductible donations" which would eliminate PACs (including superPACs). Would still allow some very large organizations (e.g. Red Cross, UNICEF), but I'm not sure that's entirely bad if we include the size limits under discussion as subcategories for I (especially J or K).</li><li class="">I agree that this should be modified and discussed, not rejected out of hand.</li><li class=""> "tax deductiblity" is a rathole you don't want to go down unless you want to be incredibly US/Canada-centric about it (which I don't).</li><li class="">I don't see how this could be tuned into effectiveness across our entire service area, and strongly underscore the point that scope and budget of "not for profit" doesn't limit to 'good works' organizations and for that matter expressly excludes B corporations.</li><li class="">I take issue with characterizing any of this work done as 'out of hand'; the text here is a summary and tiny fraction of the discussions. The only "quick" decision was 'business as usual' being a non-starter.</li></ol></li></ol></li><li class="">Return to waiting list Business As Usual (Status quo - we decide that we are OK with continuing on the previous path)<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2</li><li class="">Does not address: 3, 4, 5, 6</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class="">In view of the circumstances that caused the Board to suspend the policy, I don’t believe this is viable.</li><li class="">agreed.</li><li class="">I agree we can reject this option</li><li class="">Given the board's suspension of the policy, I doubt such an action would be favored by the board. I agree this is not a viable option.</li><li class="">Agreed.</li></ol></li></ol></li><li class="">Distribute 4.1.8 space via the transfer market<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2, 3, 4, 5</li><li class="">Does not address: 6</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class="">Obviously this is 8.3 not 8.2 :) Money would go to ARIN, is there something that this money could go to? Membership cost reduction? Fellowship? Education? Bad optics because it looks like ARIN is incented to be aggressive about reclaiming space.</li><li class="">Actually addresses many of the currently-defined issues, but it smells bad to me.</li><li class="">This is similar to setting of a fee for wait-list allocations, only that it is done with the assistance of a 3rd party setting the price. I prefer a simple fee which would be adjusted annually which is a discount from the anticipated market price.</li><li class="">The boquet of limburger with the appearance of Medusa... Yeah, you are right about the optics and aroma.</li><li class="">I'm not so skeptical that this approach should be rejected. Removing/reducing the profit motive for fraudulent applications would be an effective path to curbing the abuse, and I feel that at least this should be floated as an option with the community.</li><li class="">removing the profit motive this way is very punitive to organizations that are legitimately on the waiting list. I'd hate to see ARIN end up chasing its tail the way ICANN is with their new domain make money fast slush fund.</li><li class="">At least three strong statements of support on PPML for this.</li></ol></li></ol></li><li class="">Reduce maximum 4.1.8 allocation to /19 or /18<ol style="list-style-type: lower-alpha;" class=""><li class="">Addresses: 1, 2, 5</li><li class="">Does not address: 3, 4, 6</li><li class="">Discussion<ol style="list-style-type: disc;" class=""><li class=""><br class=""><ol style="list-style-type: circle;" class=""><li class="">Disadvantages<ol style="list-style-type: square;" class=""><li class="">Doesn't really move the needle when we are seeing questionable applications in this range already</li><li class="">More a BAU policy than a smaller maximum allocation policy (current max waitlist is not codified in 4.1.8. but as a practical manner tops out around a /16 or maybe a /15?).</li><li class="">Extremely large waitlist prefixes that take literally years to bear fruit cause one to question the legitimacy of the "need" that was documented to ARIN.</li></ol></li></ol></li><li class="">again, minor incrementalism that if anything will teach the fraudsters how to adapt.</li><li class="">limited value in the promotion of larger blocks. If the community really wants larger blocks they will say so when we publish the new max size of "/22"</li></ol></li></ol></li></ol><div class=""><br class=""></div></div></div>_______________________________________________<br class="">ARIN-PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="https://lists.arin.net/mailman/listinfo/arin-ppml" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact info@arin.net if you experience any issues.<br class=""></div></blockquote></div><br class=""></body></html>