Hello Milton, > While couched as opposition your post agrees with the problem statement that > "Earlier work on this issue has > explored several options to restrict or otherwise limit out of region use. > None of these options have gained > consensus within the community." So there is no basis for opposition there.
Correct. > I would conclude, however, that you do _not_ agree with the problem > statement that "Current policy neither > clearly forbids nor clearly permits out of region use of ARIN registered > resources." You seem to believe that it > is already permitted, which makes the proposal a no-op. Is that right? Not quite. The truth of the matter is that ARIN has operated for a very long time under a rule discussed many times between the RIRs' RS staff: "The block must be routed from equipment within the RIR's region". Often times that's just anchoring the least specific. It was a very solid rule which gave international backbone operators the flexibility to use the RIR they wanted for their needs, because they anchored routes everywhere. If a content provider doesn't run an international backbone, and that content provider has its customers and equipment in, say, Malaysia, then they would generally be unable to obtain space from ARIN. The answer from ARIN for such a request would be, "No - got see APNIC or a local IR". What changed was a year or two ago, some companies got pretty clever. They actually moved their routers to datacenters on the NA west coast, and used layer 2 tunneling to get everything back to the Asian east coast. All of their customers are in Asia, and they only have a shell company set up in California for the purposes of receiving space from ARIN. The problem was compounded by two factors: 1) Some of these content providers were really, really large. China, for example, is a really big place. So the IP needs were larger than all but 1 or 2 ARIN customers. 2) Some of these requests were fraudulent. Provide fraud when dealing with operations from a wholly different culture has proven to be exceedingly difficult and, honestly, beyond ARIN's considerable expertise. This was the point at which the staff started bringing this to the PDP fora. It started in 2011 in Philadelphia, more serious alarms were raised in Arizona, and those alarms continue today. The community has been consistently deaf to these concerns. Responses range from: - I don't care; RIRs should just give space to operators who need them (region-agnostic) to - I don't care; I can't wait for IPv4 to run out. To some of us, these responses were disappointing. I can appreciate the argument that the "Regional" part of Regional Internet Registries may now be past is usefulness. But the argument has been very hard for me to swallow because there's just so much bad faith requesting going on, and it's almost all from extra-ARIN regions. This is what staff has been trying to tell you (the PP community), and this is what you (the PP community) seem to say, "so what?" to. [snip] > Your second argument is that the staff already has all the tools it needs to > do what is in section X.1. > This is not something the staff report said to us in its assessment, however, > so I would discount that. You can discount it, but I respectfully say I'm right :) I did do this, on the front lines, for 10 years, and Leslie and I developed ALL of the fraud protocols. > You main argument, therefore is that "out-of-region requestors [are] abusing > the policies" and "we need to > draft text that significantly and materially helps ARIN staff fight fraud > from out-of-region requestors." > Apparently you think the authorization to engage external entities to help > with verification does not > address that. Can you explain why? I feel like I have in my first response. X.1 is no-op because nothing changes. Staff already can and do conduct these types of activities when investigating fraud. They may not have "engaged outside entities" to help with investigation, but they've always had that purview (that is, with parties who would be under attorney-client privilege). Best regards, David David R Huberman Microsoft Corporation Senior IT/OPS Program Manager (GFS) _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
