<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 11, 2016 at 9:22 PM, Rob Seastrom <span dir="ltr"><<a href="mailto:rs@seastrom.com" target="_blank">rs@seastrom.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> On Sep 11, 2016, at 9:22 PM, John Curran <<a href="mailto:jcurran@arin.net">jcurran@arin.net</a>> wrote:<br>
><br>
> On Sep 11, 2016, at 5:20 PM, David R Huberman <<a href="mailto:daveid@panix.com">daveid@panix.com</a>> wrote:<br>
>><br>
>> John,<br>
>><br>
>> Two comments:<br>
>><br>
>> 1) Would the proposed change -- moving transfer fees to the beginning of the process -- assist ARIN staff in stemming significant amount of possibly fradulent transfer requests?<br>
><br>
> David -<br>
><br>
> Definitely - we presently have a sizable number of requests made at no cost to the requester<br>
> which do not appear to be legitimate, but are initiated speculatively and/or optimistically (i.e.<br>
> in the hope that ARIN won’t detect the attempt at hijacking) The proposed change is unlikely<br>
> to deter bona fide requests (as it does not change the cost of a successful transfer) but could<br>
> easily change the economics for ones not made in good faith.<br>
><br>
>> 2) Instead of assuming the source entity is going to be invoiced, please understand that in a 8.3 transfer, there are often 4 parties (source, recipient, broker, ARIN), and in a 8.4 transfer, there are at least 5 parties. Can ARIN please *ask* the submitter of the transfer request to identify the party who will pay the transfer fee, and create an invoice accordingly?<br>
><br>
> Interesting point - I believe this can be done (and will confirm shortly.)<br>
<br>
It seems to me that in order for this to be maximally effective at eliminating the workload associated speculative filings, ARIN would need to not only create an invoice, but delay moving forward with checking the provenance of the number resources in question until after the invoice was paid. This exercise is reminiscent of the tradeoffs in TCP fast open vs. syn cookies with an eye towards attack surface minimization.<br>
<br>
regards,<br></blockquote></div><br clear="all"><div>I agree transfer fees should be due regardless of the success of the transfer. Additionally, I think pre-payment, before any work by ARIN begins, is a justified when the source resources are not already covered under an RSA, there seems to be an additional risk of fraud in these cases. There is an argument to be made that these changes would increase the cost to the fraudsters, therefore helping to reduce occurrence of such fraud, but let's be clear, it won't eliminate fraud. </div><div><br></div><div>However, I wonder if the risk of fraud is low enough when the source resources are already covered under an RSA to allow post-payment instead of pre-payment, the fees are still due regardless of success of the transfer. Note: the RSA contract has serious consequences for failure to pay an invoices, eventually the loss of the resources. </div><div><br></div><div>Further, I think some flexibility should be provided allowing the substitution of the recipient, in cases where failure of the transfer was due to the recipient's failure to qualify to receive resource. I think there should be limits on this flexibility, like maybe two attempted substitutions within 90 days, more than that the transfer just fails and the fees are forfeit. I think this flexibility is justified because the risk of a failed request in the past has been a community risk. A recipient of resources from the free pool was only charged if they qualified, the failed requests were a community cost. </div><div><br></div><div>Finally, if a transfer request can designate the payee, then the payee should only be allowed post-payment if they have a contract with ARIN and there are serious consequences for lack of payment, like loss of resources if the invoice is not paid, otherwise pre-payment should be required. However, if designation of payee is allow, and a recipient can be designated, allowing substitution of the recipient seems out of place, and probably allows a whole in the logic. So, I think we can only have one or the other of these options, and I think I prefer the payee being the source with limited recipient substitution over payee designation. </div><div><br></div><div>What do others think?</div><div><br></div><div>Thanks.</div><div> </div>-- <br><div class="gmail_signature">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>=============================================== </div>
</div></div>