[arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks
bensons at queuefull.net
Fri Feb 25 03:12:25 EST 2011
Thanks for your thoughtful questions.
On Feb 25, 2011, at 12:02 AM, Alexander, Daniel wrote:
> Everyone likes to talk about the benefits of a market and efficiencies
> that may or may not be provided. While this model is possible, I'm trying
> to understand how this change would benefit all involved more than the
> current model. On the surface, it looks like the only ones that would
> benefit from a change like this would be those who hope to profit from
> brokering transfers. While we could open the door to opt out of services,
> this genie cannot be put back in the bottle if it's let out.
To some extent, I'm not sure the genie is under our control in the first place. But focusing on your question of "who benefits"... Prop 136 doesn't deal directly with address markets, but may help a legacy market emerge. You mentioned brokers as benefiting, which is probably true. But I would suggest that buyers and sellers would be the primary beneficiaries of a market. Consider for example: regulated industries like health care that may need access to IPv4 addresses, developing economies around the world including those in regions with fewer addresses than the ARIN region, etc. A market certainly brings with it a number of new fears, but would also have much benefit.
> While a resource holder could be given the opportunity to opt out of
> services provided by ARIN, there is no recourse in this proposal for those
> who are unable to maintain the pointers. There are also no restrictions on
> how many levels this could go if blocks were transferred repeatedly. There
> are also no obligations placed on resource holders should transfers go
> more than one level deep. And there is no way to ensure that pointers
> would remain relevant once blocks get transferred multiple times.
This is a valid point. I see two questions that need to be considered. First, I agree that the proposal would be improved by dealing with the possibility of future non-performance of the whois requirement. I'm not sure what to do about that specifically, and would welcome input.
Second, I think we need to have a discussion about deaggregation. Topmost blocks being transferred repeatedly might create a transaction cost for ARIN, but is otherwise minimal impact on the community. However, if a topmost block is parceled then there may be an undesirable effect on the routing table. My personal opinion is that this is unavoidable - new routes show up every time a new network is created or multi-homes. In fact, ARIN policy of "needs-based justification" amplifies this effect by causing networks to announce multiple smaller blocks (rather than one very large block). Nevertheless anything we can do to prevent table growth, as a result of people buying lots of small address blocks, would be good. Perhaps this could be another requirement for opt-out, such as an agreement to not deaggregate faster than 2 bits per year. Do you have any thoughts on how to deal with this?
> Law enforcement agencies, service providers, and end users already have a
> difficult time trying to track down the users of a resource in WHOIS. What
> recourse is there when broken chains are formed through opt out transfers?
> At least in the current model, the community can point to ARIN as a forum
> to direct these issues. ARIN also provides the forum for everyone on this
> list to voice issues, concerns, and suggestions for improvement. If a
> large percentage of IPv4 resource holders can opt out of ARIN registry
> services, where can one go to have their issues addressed?
If an organization were to opt-out, the goal would be for them to continue maintaining their own whois records and have ARIN point to them. Under those circumstances I think the model works. But I agree, if somebody fails to maintain their delegated whois records then we have an undesired outcome. As I mentioned above, I'm interested in feedback on how to solve this. Revoking the opt-out seems awkward, but I'm not sure what else is possible.
More information about the ARIN-PPML