Just a reminder that I’d love to get comments on any and all aspects of this list by Friday (tomorrow) night.
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. Regards, -r 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. > On Mar 7, 2019, at 1:34 PM, Rob Seastrom <[email protected]> wrote: > > > Dear Colleagues, > 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. > I have incorporated feedback on 2019-2 on PPML up to 1315 EST today. > I'll be incorporating feedback on this thread into our working documents on > Friday, March 15th, so please expedite your thoughtful responses. > 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 > https://technotes.seastrom.com/assets/2019-03-07-NRPM-4-1-8-Policy-Actions/2019-03-07-NRPM-4-1-8-Policy-Actions.pdf > > <https://technotes.seastrom.com/assets/2019-03-07-NRPM-4-1-8-Policy-Actions/2019-03-07-NRPM-4-1-8-Policy-Actions.pdf> > Kind regards, > -r > > Problem Space > > 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). > 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. > 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. > 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. > 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. > 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. > Discussion: > > 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. > 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. > 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.) 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... > 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. > Certainly a possibility (one way gate... all new applications would be > placed on the waiting list and immediately filled if possible.) for > addressing the issue. > 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. > It is not reasonable to ask the Community to weigh in policies based on > allegations of fraud without data from Registration Services ( + 3) > Summary data posted to PPML in Message-ID: > <[email protected] > <mailto:[email protected]>> > Sweeting's Policy Experience Report from ARIN 42 in Vancouveris available in > the following locations: > Transcript: > https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcript.html#anchor_5 > > <https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcript.html#anchor_5> > > Youtube: https://www.youtube.com/watch?v=MJHgs4wWO58 > <https://www.youtube.com/watch?v=MJHgs4wWO58> > Presentation: > https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/sweeting-policy.pdf > > <https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/sweeting-policy.pdf> > > > > > > > Potential Policy Actions > > 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”. > > > > > > > Policy Menu for discussion > > 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. > Addresses: 1, 2, 5 plus overlay on particular policy actions > Does not address: overlay on particular policy actions > Discussion > 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? > 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. > 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. > 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). > 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. > 4.1.8 space to be held in a “replenishment pool” for 4.4/4.10 (or similar) > Addresses: 1, 2, 3, 5 > Does not address: 6 > Discussion > 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. > Unlikely to see community support; also sends wrong message about the future > of IPv4. > 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. > 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"). > Distribute 4.1.8 space with a one time issuance surcharge attached - "the > board should consider implementing a fee structure." > Addresses: 1, 2, 5 > Does not address: 6 > Discussion > 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. > Possibly address items 3 & 4, but I’m concerned that the fee would have to be > significantto 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. > 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. > Make 4.1.8 space non-transferrable (must return to ARIN). > Addresses: 1, 2, 3, 5 > Does not address: 6 > Discussion > 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. > 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. > non-transferable still means people can lease/reallocate. > 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?) . > 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). > The reason I put 'does not address 6' is it does not specifically favor or > disfavour. > 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. > Longer holddown period for transfer after receiving 4.1.8 space > Addresses: 1, 2, 5 > Does not address: 6 > Discussion > 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 > 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. > I think this is just a less-effective alternative to D. I nominate this one > for the considered and rejected bucket on that basis. > 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. > Only one 4.1.8 application / grant per applicant (no getting back in line/one > bite at the apple) > Addresses: 1, 2, 5, 6 > Does not address: 3, 4 > Discussion > 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. > 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. > 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. > No 4.1.8 applications for any existing V4 resource holder > Addresses: 1, 2, 5, 6 > Does not address: 3, 4 > Discussion > Same as “no getting back in line” - creating shell organizations for the > purpose of getting space from ARIN. TODO - Get quotes from > https://www.delreg.com <https://www.delreg.com/>for fixed and variable costs > of setting up a shell corporation and add in the minimum documentation > overhead to make a model. > I’m sure I could spend time finding current rates, but here’s 2015 data, that > sticks to my “very low” answer > https://blog.corpnet.com/fees-incorporating-state-understand-costs-corporation/ > > <https://blog.corpnet.com/fees-incorporating-state-understand-costs-corporation/>. > 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”. > 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). > To me, this is just a more obnoxious form of F and I believe it should suffer > the same suggested fate. > 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: > https://www.apnic.net/community/policy/proposals/prop-129 > <https://www.apnic.net/community/policy/proposals/prop-129>. > 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. > Addresses: 1, 2, 4 > Does not address: 3, 5, 6 > Discussion > 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. > I don’t know how much of the fraud this would actual cut into, being a > reference to other entities on the list. > 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. > 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)} > 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. > Reduce maximum allocation for 4.1.8 space (general action - subsequent are > more specific) > Addresses: 1, 2, 4, 5, 6 > Does not address: > Discussion > > Advantages > Increases the number of organizations that can be served. > Lessens the impact of "loophole applications" that make it through > The necessity of repeated transactions (grant events) in order to amass a > significant amount of space increases the paper trail for detecting > undesirable behavior. > Disadvantages > 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. > 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. > Increased workload on Registration Services (operational issue outside of the > scope of our policy discussion) > I think this is a required piece of any solution. Reduces but wouldn’t > eliminate 3 > I also think this is a required part of any solution as long as the solution > isn't "transfer at market price" > Agree this is the single best action we can take and is likely improved by > combining with other action(s) (notably D) > Per item 6, I'm less concerned about deserving organizations getting limited > space. > 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. > Agree with the comments above that this needs to be part of the solution but > not the only solution > Reduce maximum 4.1.8 allocations to /24 (or more likely "minimum allocation > as elsewhere in policy") > Addresses: 1, 2, 3, 4, 5, 6 > Does not address: n/a > Discussion > > Advantages > Serves the most number of organizations > Maximally reduces fraud incentive, particularly when combined with "one grant > per applicant" > Maximizes grant events (see I.c.c above) for detecting activity by bad actors > RIPE is about to do it (see RIPE-2019-02:Reducing IPv4 Allocations to a /24) > https://www.ripe.net/participate/policies/proposals/2019-02 > <https://www.ripe.net/participate/policies/proposals/2019-02>https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-February/012623.html > > <https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-February/012623.html> > Disadvantages > Maximizes the number of organizations that could justify more yet are > shortchanged > 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. > 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 > 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. > 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. > 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. > Reduce maximum 4.1.8 allocations to /22 > Addresses: 1, 2, 5 > Does not address: 3, 4, 6 > Discussion > > Still substantially no questionable applications at this level under today's > policies > Able to serve a greater diversity of organizations that could justify more > space than a /24 (think WISP, boutique cloud providers). > 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. > 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. > /22 seems like a good place to start the discussion on a new max block size > I agree with the /22. > 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) > I believe this combined with D is probably our best choice. > Increased number of transactions going past Registration Services is good for > discerning patterns. > if increased transactions are good, then isn't that an even better argument > for (J) and moving to /24s? > 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 neverseen 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. > I believe this or J in combination with D is the best choice. I could > probably be convinced either way on /24 or /22. > 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. > 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. > Reduce maximum 4.1.8 allocations to /21 or /20 > Addresses: 1, 2, 5 > Does not address: 3, 4, 6 > Discussion > : > Advantages > Still substantially no questionable applications at this level under today's > policies > Disadvantages > at 8 or 16x the payout per transaction, a tempting place for attempted > loopholing to land. > Nevertheless, a loophole /20 consumes 1/16 the resources of a loophole /16 > (most of these are in the /17-/18 range but still...) > I don’t think this level of incrementalism will buy us much of anything. > /22 seems like a good place to start the discussion on a new max block size > 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 > > > > Policy options considered and rejected > > No longer reissue 4.1.8 space (i.e. continue waiting list suspension > indefinitely) > Addresses: 3, 4, 5 > Does not address: 1, 2, 6 > Discussion > 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. > firmly agreed. > 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. > 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. > ARIN Stops accepting applications for 4.1.8 space, only supporting transfer > (8.x), critical infrastructure (4.4), or IPv6 transition (4.10) policies > Addresses: 3, 4, 5 > Does not address: 1, 2, 6 > Discussion > 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. > firmly agreed. > This is smilar to the B above, so why is this specifically rejected it seems > similar. > Prioritize "not for profit" organizations’ applications for 4.1.8 space, > potentially to the exclusion of all others. > Addresses: 1, 2, 5, 6 > Does not address: 3, 4 > Discussion > such status is merely an artifact of national tax laws; they say nothing > about budgets or size. > agreed; would include superPACs in the US. > 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. > 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). > I agree that this should be modified and discussed, not rejected out of hand. > "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). > 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. > 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. > Return to waiting list Business As Usual (Status quo - we decide that we are > OK with continuing on the previous path) > Addresses: 1, 2 > Does not address: 3, 4, 5, 6 > Discussion > In view of the circumstances that caused the Board to suspend the policy, I > don’t believe this is viable. > agreed. > I agree we can reject this option > 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. > Agreed. > Distribute 4.1.8 space via the transfer market > Addresses: 1, 2, 3, 4, 5 > Does not address: 6 > Discussion > 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. > Actually addresses many of the currently-defined issues, but it smells bad to > me. > 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. > The boquet of limburger with the appearance of Medusa... Yeah, you are right > about the optics and aroma. > 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. > 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. > At least three strong statements of support on PPML for this. > Reduce maximum 4.1.8 allocation to /19 or /18 > Addresses: 1, 2, 5 > Does not address: 3, 4, 6 > Discussion > > Disadvantages > Doesn't really move the needle when we are seeing questionable applications > in this range already > 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?). > 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. > again, minor incrementalism that if anything will teach the fraudsters how to > adapt. > 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" > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues.
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
