[arin-ppml] Transparency on IPv4 transfers

[Michel Py]

Hi David,

> David Farmer a écrit :
> I'm sympathetic to the pricing transparency argument.  However, how does ARIN know what is
> reported to it is actually correct? ARIN isn't a direct party to the financial transactions,
> so it has no direct knowledge to determine the accuracy of what is reported to it.

Correct.

> Maybe if an escrow agent is involved, they could be trusted third parties that ARIN could
> believe, I suspect they would be violating banking laws if they report false information.

That sounds impractical to me. ARIN has no relationship with them, they have no incentive in reporting, there is probably no way ARIN could force them to do so, more work that they don't want, etc. I think that we will have to rely on data provided by parties directly involved with ARIN.

> Furthermore, financial transactions are not the basis for and are not associated with all
> transfers, yes they are for many if not most, but not all. I know for a fact, a number of
> transfers have been made from a non-profit resource holder that no longer operates a
> network and no longer wants to manage reassignments on behalf of its former customers that
> were made in the '90s when it still operated a network and is now transferring the resources
> in question to the users of the reassignments, without any financial transaction being involved.

Ack that as well. However, these transactions will likely not go through a broker.

> So, as I said I'm sympathetic to the pricing transparency argument. However, what
> kind of transparency would untrustworthy data actually provide? In this case, I'm 
> afraid untrustworthy or potentially bad data is worse than no data at all. 

I agree. What we want to have is a good enough or better than what we have now picture.
That includes discarding data that is untrustworthy.

What I had in mind is that both the broker and the seller, while in the process of a transfer, each report separately the amount of the transaction.
If my memory is correct, there is a ticket open with ARIN in the process, so it could be as simple as ARIN asking both the recipient of the transfer and the broker what the transaction amount was, and check for discrepancy there.


> Is voluntarily reporting good enough? If it is, then why involve ARIN in the first place?

I don't think it is good enough; but anyway, someone has to consolidate the data.

> If voluntarily reporting is good enough, have the brokers serve this function, as IPv4.global is already doing.
> At least the brokers are a party to the financial transactions and have direct knowledge that ARIN doesn't currently have.

That would work, although relying only on broker data is not as good as what I mentioned above, both recipient and broker data with a discrepancy check. And we still need someone to consolidate the data from all of the brokers.

> How do we ensure the trustworthiness of the data?

If we implement a two-party reporting as I suggested, untrustworthy data will happen only if somehow the broker and the recipient are in bed together, which is entirely possible but we need to understand what the use case is.


> Maybe requiring officer attestation or notarized documentation of the price paid would get us there, I'm not sure.

I would not go that far. We don't want it to look like a stick, we want it to look like a carrot.

I was thinking as why we would get bad data. If the broker and the recipient are in bed together to report fake data, there must be a reason behind it.
Call it tax optimization, fraud, whatever. They are somehow cooking the books.
Let's say the real amount of the transaction is $5/IP, or $50/IP.
In that case, I would expect that they would report the transaction for an amount that is right in the middle of the market, because the last thing they want is give any clue to anybody about their unsavory accounting practice.

The point here is : that fake data would not skew the real numbers.

Michel.


Thanks



On Sun, Oct 27, 2019 at 8:38 PM Michel Py <michel at arneill-py.sacramento.ca.us> wrote:
Dear ARIN members,

I am moving here (where it belongs) a thread that started on nanog this week-end.
Long story made short, I was suggesting that ARIN collects and publish financial data associated with NPRM 8.3 and possibly more transfers.
Owen stated that he was "ambivalent" about it, which I interpret as a good state of mind for a dialog.

Problem statement :
At least one broker makes available the price paid by the recipient of transfers :
https://auctions.ipv4.global/prior-sales

My idea is as follows : I think this brings transparency to the market, and that ARIN should collect the data and publish it, so we have a more accurate picture of what the market is, and not only partial data from a small subset of brokers. We need better data.

I like the idea of transparency. It may not be fashionable to say so, but auctions.ipv4.global somehow is the eBay of the transfer market and I like it.

As a "buyer" I want to "buy" (note the quotes) a block of IPv4 addresses.
Transparency on the market is good to me, because if I do my homework right I can expect a reasonably good estimate of what it is going to cost me.

As a "seller" I want to "sell" (note the quotes) a block of IPv4 addresses.
Transparency on the market is good to me, because if I do my homework right I can expect a reasonably good estimate of what I can get out of it.

I think that there was a pretty good understanding that, if ARIN did not embrace the transfer market, there would have been a black market anyway.
My suggestion is : transparent pricing is the next step. I am not suggesting that ARIN becomes the eBay of market transfers, but I am suggesting that ARIN publishes data about market pricing.

Your comments are welcome.

Michel.

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.



-- 
===============================================
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
===============================================