[ARIN-consult] Consultation on Transfer Fees Now Open

[David Farmer]

On Sun, Sep 11, 2016 at 9:22 PM, Rob Seastrom <rs at seastrom.com> wrote:

>
> > On Sep 11, 2016, at 9:22 PM, John Curran <jcurran at arin.net> wrote:
> >
> > On Sep 11, 2016, at 5:20 PM, David R Huberman <daveid at panix.com> wrote:
> >>
> >> John,
> >>
> >> Two comments:
> >>
> >> 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?
> >
> > David -
> >
> > Definitely - we presently have a sizable number of requests made at no
> cost to the requester
> > which do not appear to be legitimate, but are initiated speculatively
> and/or optimistically (i.e.
> > in the hope that ARIN won’t detect the attempt at hijacking)   The
> proposed change is unlikely
> > to deter bona fide requests (as it does not change the cost of a
> successful transfer) but could
> > easily change the economics for ones not made in good faith.
> >
> >> 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?
> >
> > Interesting point - I believe this can be done (and will confirm
> shortly.)
>
> 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.
>
> regards,
>

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.

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.

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.

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.

What do others think?

Thanks.

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20160912/996c961d/attachment.html>