[arin-ppml] Draft Policy 2010-14: Standardize IP Reassignment Registration Requirements
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
As we struggle to put IPv6 in users' hands, we need extra red tape like a we
need holes in the head.
So, I propose this compromise:
Let's optimize the documentation requirements and let's publish them.
But let's include this caveat:
"In the interests of facilitating IPv6 deployment, IPv6 reassignment
documentation requirements shall not be enforced before 1/1/2015."
[[WEG]] I am vehemently opposed to this proposed modification.
Put bluntly, this is short-sighted "kicking the can down the road" with no means to ensure a change in situation at the end of the delay period, while being injurious to those who need access to this information during the delay period.
Fast-forward to 2015 (or 2012 as Owen proposed) and the same folks who are bothered by a documentation requirement today will now complain that they didn't do anything with documentation upon initial deployment because they weren't required to, and now they have this huge mountain of work that they have to do to retroactively implement/validate/update their documentation so that it's useful and accurate. Even if they simply need to translate their existing internal records to something that can be updated in the RIR's systems, that likely won't be significantly easier in 2 years than it is today. Or worse, "there's no way I can make this accurate because I didn't keep good records to start with because it was hard and you didn't require it." And of course ARIN will now have a large volume of work in having to enforce updating/validating existing records, something they're already challenged to do in IPv4, and have little leverage to enforce.
And the refrain will be, "well you didn't make us do it to start with, so obviously it's not important, why are you making us do it now all of the sudden?"
Meanwhile as IPv6 deployment increases, LEAs and operators will have more and more difficulty managing problems, rooting out Spam, botnets and viruses, etc due to a phenomenal lack of information on whom to contact regarding a certain address block, and IPv6 gains a reputation as a place to hide illicit activity because it's impossible to manage/track/enforce the way that IPv4 is. It's already going to be hard enough for LEAs and others to catch up to the realities of getting to IPv4 parity on real production IPv6 deployments. So to turn your argument on its ear - they need an additional challenge in managing the transition to IPv6 in their area of the universe like they need a hole in the head.
While those with no plans to manage their documentation might save time/money in implementing a plan to update ARIN records, they'll give back a lot of it when LEAs and operators are forced to contact them directly to enforce their AUP on their end customers, serve subpoenas, fix routing problems. It wastes a lot of everyone's time for no good reason.
Part of deploying IPv6 is managing documentation as required by the internet community and the RIR policy. It's cost of doing business, just as it is with IPv4. I agree that we don't want additional barriers to entry, but this is not a good way to solve that problem, and ultimately, I think that we're rapidly moving beyond the point where barriers to entry actually matters for IPv6 adoption.
The IPv4 party is over next year. If you don't at least have a plan to do IPv6, you no longer have a viable long-term business model (at least as far as interacting with the Internet is concerned). That would be a major barrier *against* entry that trumps a relatively straightforward documentation requirement as a barrier *to* entry.
You want to help? Make a public domain/GPL address management system or other resources available that handles the SWIP or Rwhois interaction with the RIR to ease this as a headache or cost for address holders. Or make sure that the requirement for documentation is giving LEA and operators the info they need without generating increased effort in documenting things that they don't. The answer is *not* to remove the requirement for documentation altogether, delayed or permanently.
This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.