From narten at us.ibm.com Fri Oct 4 00:53:02 2013 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 04 Oct 2013 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201310040453.r944r28S024059@rotala.raleigh.ibm.com> Total of messages in the last 7 days. script run at: Fri Oct 4 00:53:02 EDT 2013 Messages | Bytes | Who --------+------+--------+----------+------------------------ --------+------+--------+----------+------------------------ From narten at us.ibm.com Fri Oct 4 08:42:50 2013 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 04 Oct 2013 08:42:50 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201310041242.r94Cgo5h031855@rotala.raleigh.ibm.com> Total of 10 messages in the last 7 days. script run at: Fri Oct 4 08:42:50 EDT 2013 Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.00% | 2 | 16.74% | 16139 | drc at virtualized.org 20.00% | 2 | 15.08% | 14537 | jcurran at arin.net 10.00% | 1 | 22.93% | 22104 | celestea at usc.edu 10.00% | 1 | 16.25% | 15670 | info at arin.net 10.00% | 1 | 8.79% | 8475 | david.huberman at microsoft.com 10.00% | 1 | 7.02% | 6772 | bill at herrin.us 10.00% | 1 | 6.86% | 6618 | narten at us.ibm.com 10.00% | 1 | 6.33% | 6103 | owen at delong.com --------+------+--------+----------+------------------------ 100.00% | 10 |100.00% | 96418 | Total From jcurran at arin.net Fri Oct 4 15:55:59 2013 From: jcurran at arin.net (John Curran) Date: Fri, 4 Oct 2013 19:55:59 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> Message-ID: <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> Gary - Since June 2013, there have been 52 requests that would not have been approved under the new policy because these organizations had only some equipment in a data center in the ARIN region, but either all or most of their technical infrastructure outside of the region and most or all of their customers outside of the ARIN region. Total amount of space issued to these 52 organizations: 9,672 /24s, (which is a bit more than a /11 in total) and nearly all organizations were based in the APNIC region. FYI, /John John Curran President and CEO ARIN > On Sep 27, 2013, at 11:37 PM, John Curran wrote: > >> On Sep 26, 2013, at 3:06 PM, Gary Buhrmaster wrote: >> >>> On Thu, Sep 26, 2013 at 6:21 PM, John Curran wrote: >>> ... >>> That is correct (and reflects current practice handling resource requests.) >> >> John, >> >> I support the policy, but I do have a few questions that >> would help finalize my thinking (that I do not recall seeing >> asked or answered). I understand that any answers are >> going to be more WAGs than facts, and you may not >> have the information or ability to provide the answers, >> but any answers would help me (and perhaps others) >> recognize the implications of such a change (if any)? >> I'll accept as many additional caveats you want to add >> to any response. >> >> * If this policy was in place for (say) the last year, what >> is the order of magnitude of number of requests that >> would have been referred to another RIR (1, 10, 100, 1000)? >> >> * If this policy was in place for (say) the last year, can >> you break down the requests by the RIR that the >> requester appeared to be have their plurality? >> >> * If this policy was in place for (say) the last year, what >> is the order of magnitude of the IPv4 numbers that >> would not have been issued by ARIN (/24 ... /8)? > > Gary - > > We're looking into your concerns, and will see whether we > can provide any insights/WAGs can be provided regarding > the potential impact of the policy (as compared to past > requests.) > > Thanks for the thought-provoking questions! > /John > > John Curran > President and CEO > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From frnkblk at iname.com Fri Oct 4 16:31:32 2013 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 4 Oct 2013 15:31:32 -0500 Subject: [arin-ppml] Out-of-region overreaction? Message-ID: <00ef01cec140$b6ccb5e0$246621a0$@iname.com> I was requesting some ISP IPv6 space and the kindly ARIN staff posted this in their response: Please reply and verify that you will be using the requested number resources within the ARIN region and announcing all routing prefixes of the requested space from within the ARIN region. In accordance with section 2.2 of the NRPM, ARIN issues number resources only for use within its region. ARIN is therefore only able to provide for your in-region numbering needs.? I'm familiar with the concern about out-of-region folk taking advantage of ARIN's current IPv4 supply, but I have a few concerns about the wording of the staff communication. a) It's been my understanding thus far that if I'm an ISP that provides service in multiple places around the world that I may divide my allocation into smaller prefixes and advertise those to area peers. It seems ARIN staff would preclude me from doing any of that. "All" is a pretty strong word, and if ARIN really believes it, a lot of violators could be found. b) It seems that Section 2.2 of the NRPM is being misapplied. 2.2. Regional Internet Registry (RIR) Regional Internet Registries (RIRs) are established and authorized by respective regional communities, and recognized by the IANA to serve and represent large geographical regions. The primary role of RIRs is to manage and distribute public Internet address space within their respective regions. While ARIN does issue numbers within its region, section 2.2 does not say "only for use". If an "only" had be applied, I would suggest that it's "only manage and distribute". If I could be so bold, I'd suggest ARIN to use language something along these lines in their communications: Please reply and verify that you will be using the requested number resources primarily within the ARIN region and announcing the majority of routing prefixes of the requested space from within the ARIN region. In accordance with section 2.2 of the NRPM, ARIN issues number resources within its region. Frank From scottleibrand at gmail.com Fri Oct 4 17:42:50 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 4 Oct 2013 14:42:50 -0700 Subject: [arin-ppml] Out-of-region overreaction? In-Reply-To: <00ef01cec140$b6ccb5e0$246621a0$@iname.com> References: <00ef01cec140$b6ccb5e0$246621a0$@iname.com> Message-ID: Agreed. IMO this is *not* was intended by current policy, *particularly* IPv6 policy. If you get a /32, there's no reason you shouldn't be able to use it globally. Thanks for bringing this up. I think we're going to have a lively discussion next week in Phoenix. :-) -Scott On Fri, Oct 4, 2013 at 1:31 PM, Frank Bulk wrote: > I was requesting some ISP IPv6 space and the kindly ARIN staff posted this > in their response: > > Please reply and verify that you will be using > the requested number resources within the ARIN region > and announcing all routing prefixes of the requested > space from within the ARIN region. In accordance with > section 2.2 of the NRPM, ARIN issues number resources > only for use within its region. ARIN is therefore only > able to provide for your in-region numbering needs. > > I'm familiar with the concern about out-of-region folk taking advantage of > ARIN's current IPv4 supply, but I have a few concerns about the wording of > the staff communication. > > a) It's been my understanding thus far that if I'm an ISP that provides > service in multiple places around the world that I may divide my allocation > into smaller prefixes and advertise those to area peers. It seems ARIN > staff would preclude me from doing any of that. "All" is a pretty strong > word, and if ARIN really believes it, a lot of violators could be found. > > b) It seems that Section 2.2 of the NRPM is being misapplied. > 2.2. Regional Internet Registry (RIR) > > Regional Internet Registries (RIRs) are established and > authorized by respective regional communities, and > recognized by the IANA to serve and represent large > geographical regions. The primary role of RIRs is to > manage and distribute public Internet address space > within their respective regions. > > While ARIN does issue numbers within its region, section 2.2 does not say > "only for use". If an "only" had be applied, I would suggest that it's > "only manage and distribute". > > If I could be so bold, I'd suggest ARIN to use language something along > these lines in their communications: > > Please reply and verify that you will be using > the requested number resources primarily within the > ARIN region and announcing the majority of routing prefixes > of the requested space from within the ARIN region. > In accordance with section 2.2 of the NRPM, ARIN issues > number resources within its region. > > Frank > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mysidia at gmail.com Fri Oct 4 19:25:16 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 4 Oct 2013 18:25:16 -0500 Subject: [arin-ppml] Out-of-region overreaction? In-Reply-To: <00ef01cec140$b6ccb5e0$246621a0$@iname.com> References: <00ef01cec140$b6ccb5e0$246621a0$@iname.com> Message-ID: On Fri, Oct 4, 2013 at 3:31 PM, Frank Bulk wrote: > > I'm familiar with the concern about out-of-region folk taking advantage of > ARIN's current IPv4 supply, but I have a few concerns about the wording of > the staff communication. > > a) It's been my understanding thus far that if I'm an ISP that provides > service in multiple places around the world that I may divide my allocation > into smaller prefixes and advertise those to area peers. It seems ARIN > No. You can subdelegate portions of your allocation to customers. Your upstreams are not going to necessarily let you pick apart your allocation and advertise every /29; Although ARIN staff should have no objections to this, if your upstreams will allow it, and you show that to be the case. If you are chopping up your block; you do not need a big allocation from ARIN, though, of sufficient size for all your regions. It only makes sense if you intend to keep your block _whole_; and advertise a single block in multiple regions. If you intend to chop up your blocks anyways; then a sensible thing to do is to obtain multiple blocks instead -- from the appropriate regions where they will be used. > staff would preclude me from doing any of that. "All" is a pretty strong > word, and if ARIN really believes it, a lot of violators could be found. > Routing is out of scope of ARIN policy in the first place; you have an option of not advertising your allocation at all. You are allowed to have a privately interconnected network that spans regions. ARIN staff can reject your verification justification for the allocation; if you don't show you have an intention to use a significant amount of resources in the ARIN region While ARIN does issue numbers within its region, section 2.2 does not say > "only for use". If an "only" had be applied, I would suggest that it's > "only manage and distribute". > Policy does not say "only for use"; however there is not policy specifically encouraging ARIN to recognize use outside of the ARIN region. It is not sufficient for use to merely be "allowed"; ARIN has to have procedures for validating and auditing the use. It is possible, that you may be allowed to use out of region, but not be able to cite your out of region networks requirements as justification for obtaining a larger block than if your out-of-region usage did not exist at all, or it may not be accepted as current use to satisfy utilization requirement for a future allocation. > If I could be so bold, I'd suggest ARIN to use language something along > these lines in their communications: > > Please reply and verify that you will be using > the requested number resources primarily within the > ARIN region and announcing the majority of routing prefixes > of the requested space from within the ARIN region. > In accordance with section 2.2 of the NRPM, ARIN issues > number resources within its region. > > This is very similar to the original quote of what they had said....... > Frank > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Sat Oct 5 16:38:45 2013 From: farmer at umn.edu (David Farmer) Date: Sat, 05 Oct 2013 15:38:45 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> Message-ID: <525078D5.7060107@umn.edu> On 10/4/13 14:55 , John Curran wrote: > Gary - > > Since June 2013, there have been 52 requests that would not have > been approved under the new policy because these organizations > had only some equipment in a data center in the ARIN region, but > either all or most of their technical infrastructure outside of the region > and most or all of their customers outside of the ARIN region. > > Total amount of space issued to these 52 organizations: 9,672 /24s, > (which is a bit more than a /11 in total) and nearly all organizations were based in the APNIC region. John, Thank you for the interesting stats, also thanks to Gary for asking the enlightening question. I assume this is using the "plurality" standard of the current language of 2013-6. However, there have been a number of concerns raised regarding the "plurality" standard, including comments in the staff and legal review. So, would a "20% minimum" standard be equally effective for the cases outlined above? For simplicity let's assume, assume "20% minimum", is substituted for "plurality", as the only change. Thanks -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nathaliecoupet at yahoo.com Sat Oct 5 17:04:45 2013 From: nathaliecoupet at yahoo.com (nathalie coupet) Date: Sat, 5 Oct 2013 14:04:45 -0700 (PDT) Subject: [arin-ppml] ARIN-PPML Digest, Vol 100, Issue 2 In-Reply-To: References: Message-ID: <1381007085.59696.YahooMailNeo@web124705.mail.ne1.yahoo.com> Hello John, As far as law enforcement agencies are concerned, the problem is not so much a question of depletion of the IPv4 pool but of traceability back to the attacker in case of misuse of the Internet, such as for MitMA or DDoS (many attackers of US websites being located in the APNIC/Middle East Regions). The problem is even more acute for IPv6 addresses, since blocks allocated are larger than those for IPv4. ?? Maybe ARIN's policy should be consistent regarding the allocation of both IPv4 and IPv6 addresses requesting that stakeholders have sufficient attachment to the region prior to receiving IP addresses from ARIN.? If we do not take into consideration security concerns into our own hands and decide for ourselves what we tolerate and what we don't, others will enact rules and procedures that might end up affecting the organization in a way that could really detrimental to business.? ? Nathalie Coupet ARIN Member ________________________________ From: "arin-ppml-request at arin.net" To: arin-ppml at arin.net Sent: Friday, October 4, 2013 7:32 PM Subject: ARIN-PPML Digest, Vol 100, Issue 2 Send ARIN-PPML mailing list submissions to ??? arin-ppml at arin.net To subscribe or unsubscribe via the World Wide Web, visit ??? http://lists.arin.net/mailman/listinfo/arin-ppml or, via email, send a message with subject or body 'help' to ??? arin-ppml-request at arin.net You can reach the person managing the list at ??? arin-ppml-owner at arin.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ARIN-PPML digest..." Today's Topics: ? 1. Re: Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 ? ? ? Address Space to Out-of-region Requestors - Revised (John Curran) ? 2. Out-of-region overreaction? (Frank Bulk) ? 3. Re: Out-of-region overreaction? (Scott Leibrand) ? 4. Re: Out-of-region overreaction? (Jimmy Hess) ---------------------------------------------------------------------- Message: 1 Date: Fri, 4 Oct 2013 19:55:59 +0000 From: John Curran To: Gary Buhrmaster Cc: "arin-ppml at arin.net" Subject: Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 ??? and IPv6 Address Space to Out-of-region Requestors - Revised Message-ID: <42C9B415-75DB-4AB7-955F-BD84AB9C64EC at arin.net> Content-Type: text/plain; charset="us-ascii" Gary - Since June 2013, there have been 52 requests that would not have been approved under the new policy because these organizations had only some equipment in a data center in the ARIN region, but either all or most of their technical infrastructure outside of the region and most or all of their customers outside of the ARIN region.? Total amount of space issued to these 52 organizations:? 9,672 /24s, (which is a bit more than a /11 in total) and nearly all organizations were based in the APNIC region. FYI, /John John Curran President and CEO ARIN > On Sep 27, 2013, at 11:37 PM, John Curran wrote: > >> On Sep 26, 2013, at 3:06 PM, Gary Buhrmaster wrote: >> >>> On Thu, Sep 26, 2013 at 6:21 PM, John Curran wrote: >>> ... >>> That is correct (and reflects current practice handling resource requests.) >> >> John, >> >> I support the policy, but I do have a few questions that >> would help finalize my thinking (that I do not recall seeing >> asked or answered).? I understand that any answers are >> going to be more WAGs than facts, and you may not >> have the information or ability to provide the answers, >> but any answers would help me (and perhaps others) >> recognize the implications of such a change (if any)? >> I'll accept as many additional caveats you want to add >> to any response. >> >> * If this policy was in place for (say) the last year, what >> is the order of magnitude of number of requests that >> would have been referred to another RIR (1, 10, 100, 1000)? >> >> * If this policy was in place for (say) the last year, can >> you break down the requests by the RIR that the >> requester appeared to be have their plurality? >> >> * If this policy was in place for (say) the last year, what >> is the order of magnitude of the IPv4 numbers that >> would not have been issued by ARIN (/24 ... /8)? > > Gary - > >? We're looking into your concerns, and will see whether we >? can provide any insights/WAGs can be provided regarding >? the potential impact of the policy (as compared to past >? requests.) > > Thanks for the thought-provoking questions! > /John > > John Curran > President and CEO > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. ------------------------------ Message: 2 Date: Fri, 4 Oct 2013 15:31:32 -0500 From: "Frank Bulk" To: Subject: [arin-ppml] Out-of-region overreaction? Message-ID: <00ef01cec140$b6ccb5e0$246621a0$@iname.com> Content-Type: text/plain;??? charset="iso-8859-1" I was requesting some ISP IPv6 space and the kindly ARIN staff posted this in their response: ??? Please reply and verify that you will be using ??? the requested number resources within the ARIN region ??? and announcing all routing prefixes of the requested ??? space from within the ARIN region. In accordance with ??? section 2.2 of the NRPM, ARIN issues number resources ??? only for use within its region. ARIN is therefore only ??? able to provide for your in-region numbering needs.? I'm familiar with the concern about out-of-region folk taking advantage of ARIN's current IPv4 supply, but I have a few concerns about the wording of the staff communication. a) It's been my understanding thus far that if I'm an ISP that provides service in multiple places around the world that I may divide my allocation into smaller prefixes and advertise those to area peers.? It seems ARIN staff would preclude me from doing any of that.? "All" is a pretty strong word, and if ARIN really believes it, a lot of violators could be found.? b) It seems that Section 2.2 of the NRPM is being misapplied.? ??? 2.2. Regional Internet Registry (RIR) ??? Regional Internet Registries (RIRs) are established and ??? authorized by respective regional communities, and ??? recognized by the IANA to serve and represent large ??? geographical regions. The primary role of RIRs is to ??? manage and distribute public Internet address space ??? within their respective regions. While ARIN does issue numbers within its region, section 2.2 does not say "only for use".? If an "only" had be applied, I would suggest that it's "only manage and distribute". If I could be so bold, I'd suggest ARIN to use language something along these lines in their communications: ??? Please reply and verify that you will be using ??? the requested number resources primarily within the ??? ARIN region and announcing the majority of routing prefixes ??? of the requested space from within the ARIN region. ??? In accordance with section 2.2 of the NRPM, ARIN issues ??? number resources within its region. Frank ------------------------------ Message: 3 Date: Fri, 4 Oct 2013 14:42:50 -0700 From: Scott Leibrand To: Frank Bulk Cc: ARIN-PPML List Subject: Re: [arin-ppml] Out-of-region overreaction? Message-ID: ??? Content-Type: text/plain; charset="iso-8859-1" Agreed.? IMO this is *not* was intended by current policy, *particularly* IPv6 policy.? If you get a /32, there's no reason you shouldn't be able to use it globally. Thanks for bringing this up.? I think we're going to have a lively discussion next week in Phoenix.? :-) -Scott On Fri, Oct 4, 2013 at 1:31 PM, Frank Bulk wrote: > I was requesting some ISP IPv6 space and the kindly ARIN staff posted this > in their response: > >? ? ? ? Please reply and verify that you will be using >? ? ? ? the requested number resources within the ARIN region >? ? ? ? and announcing all routing prefixes of the requested >? ? ? ? space from within the ARIN region. In accordance with >? ? ? ? section 2.2 of the NRPM, ARIN issues number resources >? ? ? ? only for use within its region. ARIN is therefore only >? ? ? ? able to provide for your in-region numbering needs. > > I'm familiar with the concern about out-of-region folk taking advantage of > ARIN's current IPv4 supply, but I have a few concerns about the wording of > the staff communication. > > a) It's been my understanding thus far that if I'm an ISP that provides > service in multiple places around the world that I may divide my allocation > into smaller prefixes and advertise those to area peers.? It seems ARIN > staff would preclude me from doing any of that.? "All" is a pretty strong > word, and if ARIN really believes it, a lot of violators could be found. > > b) It seems that Section 2.2 of the NRPM is being misapplied. >? ? ? ? 2.2. Regional Internet Registry (RIR) > >? ? ? ? Regional Internet Registries (RIRs) are established and >? ? ? ? authorized by respective regional communities, and >? ? ? ? recognized by the IANA to serve and represent large >? ? ? ? geographical regions. The primary role of RIRs is to >? ? ? ? manage and distribute public Internet address space >? ? ? ? within their respective regions. > > While ARIN does issue numbers within its region, section 2.2 does not say > "only for use".? If an "only" had be applied, I would suggest that it's > "only manage and distribute". > > If I could be so bold, I'd suggest ARIN to use language something along > these lines in their communications: > >? ? ? ? Please reply and verify that you will be using >? ? ? ? the requested number resources primarily within the >? ? ? ? ARIN region and announcing the majority of routing prefixes >? ? ? ? of the requested space from within the ARIN region. >? ? ? ? In accordance with section 2.2 of the NRPM, ARIN issues >? ? ? ? number resources within its region. > > Frank > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Fri, 4 Oct 2013 18:25:16 -0500 From: Jimmy Hess To: Frank Bulk Cc: "arin-ppml at arin.net" Subject: Re: [arin-ppml] Out-of-region overreaction? Message-ID: ??? Content-Type: text/plain; charset="iso-8859-1" On Fri, Oct 4, 2013 at 3:31 PM, Frank Bulk wrote: > > I'm familiar with the concern about out-of-region folk taking advantage of > ARIN's current IPv4 supply, but I have a few concerns about the wording of > the staff communication. > > a) It's been my understanding thus far that if I'm an ISP that provides > service in multiple places around the world that I may divide my allocation > into smaller prefixes and advertise those to area peers.? It seems ARIN > No.? ? You? can subdelegate portions of your allocation to customers. Your upstreams are not going to necessarily let you pick apart your allocation and advertise every /29;? ? Although? ARIN staff should have no objections to this, if your upstreams will allow it,? and you show that to be the case. If you are chopping up your block; you do not need a big allocation from ARIN, though, of sufficient size for all your regions.? It only makes sense if you intend to keep your block _whole_; and advertise a single block in multiple regions. If you intend to chop up your blocks anyways;? then a sensible thing to do is to obtain? multiple blocks instead -- from the appropriate regions where they will be used. > staff would preclude me from doing any of that.? "All" is a pretty strong > word, and if ARIN really believes it, a lot of violators could be found. > Routing is out of scope of ARIN policy in the first place;? you have an option of not advertising your allocation at all.? ? You are allowed to have a privately interconnected network that spans regions. ARIN staff can reject your verification justification for the allocation; if you don't show you have an intention to use a significant amount of resources in the ARIN region While ARIN does issue numbers within its region, section 2.2 does not say > "only for use".? If an "only" had be applied, I would suggest that it's > "only manage and distribute". > Policy does not say "only for use";? however there is not policy specifically encouraging ARIN to recognize use outside of the ARIN region. It is not sufficient for use to merely be "allowed";? ARIN has to have procedures for validating and auditing the use. It is possible, that you may be allowed to use out of region, but not be able to cite your? out of region networks requirements? as justification for obtaining a larger block? than? if your out-of-region usage? did not exist at all, or it may not be accepted as current use to satisfy utilization requirement for a future allocation. > If I could be so bold, I'd suggest ARIN to use language something along > these lines in their communications: > >? ? ? ? Please reply and verify that you will be using >? ? ? ? the requested number resources primarily within the >? ? ? ? ARIN region and announcing the majority of routing prefixes >? ? ? ? of the requested space from within the ARIN region. >? ? ? ? In accordance with section 2.2 of the NRPM, ARIN issues >? ? ? ? number resources within its region. > > This is very similar to? the original quote of what they had said....... > Frank > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml End of ARIN-PPML Digest, Vol 100, Issue 2 ***************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Sat Oct 5 17:32:00 2013 From: jcurran at arin.net (John Curran) Date: Sat, 5 Oct 2013 21:32:00 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <525078D5.7060107@umn.edu> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net>, <525078D5.7060107@umn.edu> Message-ID: On Oct 5, 2013, at 4:38 PM, "David Farmer" wrote: > > > So, would a "20% minimum" standard be equally effective for the cases outlined above? For simplicity let's assume, assume "20% minimum", is substituted for "plurality", as the only change. David - It would be materially the same outcome as the plurality language. FYI, /John John Curran President and CEO ARIN From mskojec at virtacore.com Sat Oct 5 17:35:04 2013 From: mskojec at virtacore.com (Skojec, Martin) Date: Sat, 5 Oct 2013 17:35:04 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 100, Issue 2 In-Reply-To: <1381007085.59696.YahooMailNeo@web124705.mail.ne1.yahoo.com> References: <1381007085.59696.YahooMailNeo@web124705.mail.ne1.yahoo.com> Message-ID: Hi Nathalie, I appreciate your views but I don't think that the law enforcement's insight should even be considered in this discussion. I have no security concerns because I secure my networks. That will not change if it's IPv4 or IPv6. Both ranges will be trackable so I see no reason to change things. On Sat, Oct 5, 2013 at 5:04 PM, nathalie coupet wrote: > Hello John, > > As far as law enforcement agencies are concerned, the problem is not so > much a question of depletion of the IPv4 pool but of traceability back to > the attacker in case of misuse of the Internet, such as for MitMA or DDoS > (many attackers of US websites being located in the APNIC/Middle East > Regions). The problem is even more acute for IPv6 addresses, since blocks > allocated are larger than those for IPv4. > Maybe ARIN's policy should be consistent regarding the allocation of both > IPv4 and IPv6 addresses requesting that stakeholders have sufficient > attachment to the region prior to receiving IP addresses from ARIN. > If we do not take into consideration security concerns into our own hands > and decide for ourselves what we tolerate and what we don't, others will > enact rules and procedures that might end up affecting the organization in > a way that could really detrimental to business. > > > Nathalie Coupet > ARIN Member > > ------------------------------ > *From:* "arin-ppml-request at arin.net" > *To:* arin-ppml at arin.net > *Sent:* Friday, October 4, 2013 7:32 PM > *Subject:* ARIN-PPML Digest, Vol 100, Issue 2 > > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 > Address Space to Out-of-region Requestors - Revised (John Curran) > 2. Out-of-region overreaction? (Frank Bulk) > 3. Re: Out-of-region overreaction? (Scott Leibrand) > 4. Re: Out-of-region overreaction? (Jimmy Hess) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 4 Oct 2013 19:55:59 +0000 > From: John Curran > To: Gary Buhrmaster > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 > and IPv6 Address Space to Out-of-region Requestors - Revised > Message-ID: <42C9B415-75DB-4AB7-955F-BD84AB9C64EC at arin.net> > Content-Type: text/plain; charset="us-ascii" > > Gary - > > Since June 2013, there have been 52 requests that would not have > been approved under the new policy because these organizations > had only some equipment in a data center in the ARIN region, but > either all or most of their technical infrastructure outside of the region > and most or all of their customers outside of the ARIN region. > > Total amount of space issued to these 52 organizations: 9,672 /24s, > (which is a bit more than a /11 in total) and nearly all organizations > were based in the APNIC region. > > FYI, > /John > > John Curran > President and CEO > ARIN > > > On Sep 27, 2013, at 11:37 PM, John Curran wrote: > > > >> On Sep 26, 2013, at 3:06 PM, Gary Buhrmaster > wrote: > >> > >>> On Thu, Sep 26, 2013 at 6:21 PM, John Curran wrote: > >>> ... > >>> That is correct (and reflects current practice handling resource > requests.) > >> > >> John, > >> > >> I support the policy, but I do have a few questions that > >> would help finalize my thinking (that I do not recall seeing > >> asked or answered). I understand that any answers are > >> going to be more WAGs than facts, and you may not > >> have the information or ability to provide the answers, > >> but any answers would help me (and perhaps others) > >> recognize the implications of such a change (if any)? > >> I'll accept as many additional caveats you want to add > >> to any response. > >> > >> * If this policy was in place for (say) the last year, what > >> is the order of magnitude of number of requests that > >> would have been referred to another RIR (1, 10, 100, 1000)? > >> > >> * If this policy was in place for (say) the last year, can > >> you break down the requests by the RIR that the > >> requester appeared to be have their plurality? > >> > >> * If this policy was in place for (say) the last year, what > >> is the order of magnitude of the IPv4 numbers that > >> would not have been issued by ARIN (/24 ... /8)? > > > > Gary - > > > > We're looking into your concerns, and will see whether we > > can provide any insights/WAGs can be provided regarding > > the potential impact of the policy (as compared to past > > requests.) > > > > Thanks for the thought-provoking questions! > > /John > > > > John Curran > > President and CEO > > 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: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > ------------------------------ > > Message: 2 > Date: Fri, 4 Oct 2013 15:31:32 -0500 > From: "Frank Bulk" > To: > Subject: [arin-ppml] Out-of-region overreaction? > Message-ID: <00ef01cec140$b6ccb5e0$246621a0$@iname.com> > Content-Type: text/plain; charset="iso-8859-1" > > I was requesting some ISP IPv6 space and the kindly ARIN staff posted this > in their response: > > Please reply and verify that you will be using > the requested number resources within the ARIN region > and announcing all routing prefixes of the requested > space from within the ARIN region. In accordance with > section 2.2 of the NRPM, ARIN issues number resources > only for use within its region. ARIN is therefore only > able to provide for your in-region numbering needs.? > > I'm familiar with the concern about out-of-region folk taking advantage of > ARIN's current IPv4 supply, but I have a few concerns about the wording of > the staff communication. > > a) It's been my understanding thus far that if I'm an ISP that provides > service in multiple places around the world that I may divide my allocation > into smaller prefixes and advertise those to area peers. It seems ARIN > staff would preclude me from doing any of that. "All" is a pretty strong > word, and if ARIN really believes it, a lot of violators could be found. > > b) It seems that Section 2.2 of the NRPM is being misapplied. > 2.2. Regional Internet Registry (RIR) > > Regional Internet Registries (RIRs) are established and > authorized by respective regional communities, and > recognized by the IANA to serve and represent large > geographical regions. The primary role of RIRs is to > manage and distribute public Internet address space > within their respective regions. > > While ARIN does issue numbers within its region, section 2.2 does not say > "only for use". If an "only" had be applied, I would suggest that it's > "only manage and distribute". > > If I could be so bold, I'd suggest ARIN to use language something along > these lines in their communications: > > Please reply and verify that you will be using > the requested number resources primarily within the > ARIN region and announcing the majority of routing prefixes > of the requested space from within the ARIN region. > In accordance with section 2.2 of the NRPM, ARIN issues > number resources within its region. > > Frank > > > > ------------------------------ > > Message: 3 > Date: Fri, 4 Oct 2013 14:42:50 -0700 > From: Scott Leibrand > To: Frank Bulk > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Out-of-region overreaction? > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Agreed. IMO this is *not* was intended by current policy, *particularly* > IPv6 policy. If you get a /32, there's no reason you shouldn't be able to > use it globally. > > Thanks for bringing this up. I think we're going to have a lively > discussion next week in Phoenix. :-) > > -Scott > > > On Fri, Oct 4, 2013 at 1:31 PM, Frank Bulk wrote: > > > I was requesting some ISP IPv6 space and the kindly ARIN staff posted > this > > in their response: > > > > Please reply and verify that you will be using > > the requested number resources within the ARIN region > > and announcing all routing prefixes of the requested > > space from within the ARIN region. In accordance with > > section 2.2 of the NRPM, ARIN issues number resources > > only for use within its region. ARIN is therefore only > > able to provide for your in-region numbering needs. > > > > I'm familiar with the concern about out-of-region folk taking advantage > of > > ARIN's current IPv4 supply, but I have a few concerns about the wording > of > > the staff communication. > > > > a) It's been my understanding thus far that if I'm an ISP that provides > > service in multiple places around the world that I may divide my > allocation > > into smaller prefixes and advertise those to area peers. It seems ARIN > > staff would preclude me from doing any of that. "All" is a pretty strong > > word, and if ARIN really believes it, a lot of violators could be found. > > > > b) It seems that Section 2.2 of the NRPM is being misapplied. > > 2.2. Regional Internet Registry (RIR) > > > > Regional Internet Registries (RIRs) are established and > > authorized by respective regional communities, and > > recognized by the IANA to serve and represent large > > geographical regions. The primary role of RIRs is to > > manage and distribute public Internet address space > > within their respective regions. > > > > While ARIN does issue numbers within its region, section 2.2 does not say > > "only for use". If an "only" had be applied, I would suggest that it's > > "only manage and distribute". > > > > If I could be so bold, I'd suggest ARIN to use language something along > > these lines in their communications: > > > > Please reply and verify that you will be using > > the requested number resources primarily within the > > ARIN region and announcing the majority of routing prefixes > > of the requested space from within the ARIN region. > > In accordance with section 2.2 of the NRPM, ARIN issues > > number resources within its region. > > > > Frank > > > > _______________________________________________ > > 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: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20131004/54de2c60/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Fri, 4 Oct 2013 18:25:16 -0500 > From: Jimmy Hess > To: Frank Bulk > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Out-of-region overreaction? > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > On Fri, Oct 4, 2013 at 3:31 PM, Frank Bulk wrote: > > > > > I'm familiar with the concern about out-of-region folk taking advantage > of > > ARIN's current IPv4 supply, but I have a few concerns about the wording > of > > the staff communication. > > > > a) It's been my understanding thus far that if I'm an ISP that provides > > service in multiple places around the world that I may divide my > allocation > > into smaller prefixes and advertise those to area peers. It seems ARIN > > > > No. You can subdelegate portions of your allocation to customers. > Your upstreams are not going to necessarily let you pick apart your > allocation > and advertise every /29; Although ARIN staff should have no objections > to this, > if your upstreams will allow it, and you show that to be the case. > > If you are chopping up your block; you do not need a big allocation from > ARIN, though, > of sufficient size for all your regions. It only makes sense if you > intend to keep your block _whole_; > and advertise a single block in multiple regions. > > If you intend to chop up your blocks anyways; then a sensible thing to do > is to obtain multiple blocks instead -- from the appropriate regions > where they will be used. > > > > > staff would preclude me from doing any of that. "All" is a pretty strong > > word, and if ARIN really believes it, a lot of violators could be found. > > > > Routing is out of scope of ARIN policy in the first place; you have an > option of > not advertising your allocation at all. You are allowed to have a > privately interconnected network > that spans regions. > > ARIN staff can reject your verification justification for the allocation; > if you don't show you have an intention > to use a significant amount of resources in the ARIN region > > While ARIN does issue numbers within its region, section 2.2 does not say > > "only for use". If an "only" had be applied, I would suggest that it's > > "only manage and distribute". > > > > Policy does not say "only for use"; however there is not policy > specifically encouraging ARIN to recognize use outside of the ARIN region. > > It is not sufficient for use to merely be "allowed"; ARIN has to have > procedures > for validating and auditing the use. > > It is possible, that you may be allowed to use out of region, but not be > able to > cite your out of region networks requirements as justification for > obtaining > a larger block than if your out-of-region usage did not exist at all, > > or it may not be accepted as current use to satisfy utilization requirement > for a future allocation. > > > > If I could be so bold, I'd suggest ARIN to use language something along > > these lines in their communications: > > > > Please reply and verify that you will be using > > the requested number resources primarily within the > > ARIN region and announcing the majority of routing prefixes > > of the requested space from within the ARIN region. > > In accordance with section 2.2 of the NRPM, ARIN issues > > number resources within its region. > > > > > This is very similar to the original quote of what they had said....... > > > > > Frank > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20131004/7e771055/attachment.html > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 100, Issue 2 > ***************************************** > > > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Martin Skojec Director of Engineering and Operations - Virtacore Systems Inc. mskojec at virtacore.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sat Oct 5 18:53:53 2013 From: bill at herrin.us (William Herrin) Date: Sat, 5 Oct 2013 18:53:53 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> Message-ID: On Fri, Oct 4, 2013 at 3:55 PM, John Curran wrote: > Since June 2013, there have been 52 requests that would not have > been approved under the new policy because these organizations > had only some equipment in a data center in the ARIN region, but > either all or most of their technical infrastructure outside of the region > and most or all of their customers outside of the ARIN region. > > Total amount of space issued to these 52 organizations: 9,672 /24s, > (which is a bit more than a /11 in total) and nearly all organizations were based in the APNIC region. Hi John, I notice from Frank Bulk's thread that ARIN has instituted a change in procedure for address allocation related to in-region use. Were the new procedures in place, how would that have impacted the 52 requests you reference? Thanks, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Sat Oct 5 20:17:35 2013 From: farmer at umn.edu (David Farmer) Date: Sat, 05 Oct 2013 19:17:35 -0500 Subject: [arin-ppml] Out-of-region overreaction? In-Reply-To: <00ef01cec140$b6ccb5e0$246621a0$@iname.com> References: <00ef01cec140$b6ccb5e0$246621a0$@iname.com> Message-ID: <5250AC1F.6070603@umn.edu> On 10/4/13 15:31 , Frank Bulk wrote: > I was requesting some ISP IPv6 space and the kindly ARIN staff posted this > in their response: > > Please reply and verify that you will be using > the requested number resources within the ARIN region > and announcing all routing prefixes of the requested > space from within the ARIN region. In accordance with > section 2.2 of the NRPM, ARIN issues number resources > only for use within its region. ARIN is therefore only > able to provide for your in-region numbering needs. > > I'm familiar with the concern about out-of-region folk taking advantage of > ARIN's current IPv4 supply, but I have a few concerns about the wording of > the staff communication. > > a) It's been my understanding thus far that if I'm an ISP that provides > service in multiple places around the world that I may divide my allocation > into smaller prefixes and advertise those to area peers. It seems ARIN > staff would preclude me from doing any of that. "All" is a pretty strong > word, and if ARIN really believes it, a lot of violators could be found. > > b) It seems that Section 2.2 of the NRPM is being misapplied. > 2.2. Regional Internet Registry (RIR) > > Regional Internet Registries (RIRs) are established and > authorized by respective regional communities, and > recognized by the IANA to serve and represent large > geographical regions. The primary role of RIRs is to > manage and distribute public Internet address space > within their respective regions. > > While ARIN does issue numbers within its region, section 2.2 does not say > "only for use". If an "only" had be applied, I would suggest that it's > "only manage and distribute". > > If I could be so bold, I'd suggest ARIN to use language something along > these lines in their communications: > > Please reply and verify that you will be using > the requested number resources primarily within the > ARIN region and announcing the majority of routing prefixes > of the requested space from within the ARIN region. > In accordance with section 2.2 of the NRPM, ARIN issues > number resources within its region. > > Frank Staff has called out this issue several times in the past couple years, and the community has failed to provide any guidance via policy several times. There is another round of discussion prompted by the staff's latest report on this issue, that is ARIN-2013-6. I'll also point out that many people already assume they must get IPv6 resources from all five RIRs to operate a global network. And, therefore they assume that they can only use resources obtained from ARIN within the ARIN region. I've run into this numerous times. Here is one example; http://new.livestream.com/internetsociety/INETDenver2013 See Time Stamp 1:34:20 I've participated in a number of similar discussion. This is particularly an issue for IPv6 because many people are just starting to deploy their IPv6 network. I really wish the community would focus on the IPv6 aspects of this issue. I think we need policy that makes is clear ARIN resource MAY be used outside the ARIN region, as long there is more than trivial use within the ARIN region, and other technical and administrative requirements are met. Right now I believe no policy is worse and more damaging for IPv6 than a compromise policy that has some reasonable restrictions. I don't see a policy allowing out of region use with no restrictions gaining consensus right now with IPv4 run-out politics going on. I would like people to think about how we want IPv6 to work for the next decade or more, focusing policy on that, and then consider IPv4 consequences of such a policy. Right now I feel IPv4 run-out issues are driving the policy discussion, and the IPv6 consequences are being ignored. So, Frank I think the most effective thing is for you, and others, to do is help shape ARIN-2013-6 into a useful and effective policy that can gain consensus. In my opinion ARIN-2013-6 is not there yet, but I'm optimistic that with feed back at the PPM and on PPML the AC can turn ARIN-2013-6 into something that can gain consensus. Thanks. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jcurran at arin.net Sun Oct 6 00:07:53 2013 From: jcurran at arin.net (John Curran) Date: Sun, 6 Oct 2013 04:07:53 +0000 Subject: [arin-ppml] Out-of-region overreaction? In-Reply-To: <00ef01cec140$b6ccb5e0$246621a0$@iname.com> References: <00ef01cec140$b6ccb5e0$246621a0$@iname.com> Message-ID: <7AA397D7-76A0-4312-A80E-CE90C34D113B@arin.net> On Oct 4, 2013, at 1:31 PM, Frank Bulk wrote: > If I could be so bold, I'd suggest ARIN to use language something along > these lines in their communications: > > Please reply and verify that you will be using > the requested number resources primarily within the > ARIN region and announcing the majority of routing prefixes > of the requested space from within the ARIN region. > In accordance with section 2.2 of the NRPM, ARIN issues > number resources within its region. Frank - We're happy to review the wording of the communications (and will do so upon disposition of Draft Policy ARIN-2013-6.) Thanks! /John John Curran President and CEO ARIN From jcurran at arin.net Sun Oct 6 00:20:58 2013 From: jcurran at arin.net (John Curran) Date: Sun, 6 Oct 2013 04:20:58 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> Message-ID: On Oct 5, 2013, at 3:53 PM, William Herrin wrote: > On Fri, Oct 4, 2013 at 3:55 PM, John Curran wrote: >> Since June 2013, there have been 52 requests that would not have >> been approved under the new policy because these organizations >> had only some equipment in a data center in the ARIN region, but >> either all or most of their technical infrastructure outside of the region >> and most or all of their customers outside of the ARIN region. >> >> Total amount of space issued to these 52 organizations: 9,672 /24s, >> (which is a bit more than a /11 in total) and nearly all organizations were based in the APNIC region. > > Hi John, > > I notice from Frank Bulk's thread that ARIN has instituted a change in > procedure for address allocation related to in-region use. Were the > new procedures in place, how would that have impacted the 52 requests > you reference? Bill - ARIN's procedures for requesters has not changed since the Policy Implementation and Experience Report addressing this topic (at the ARIN 31 meeting in Bridgetown); hence, the 52 requests would still be processed. As noted earlier to Frank, I believe that the text sent in response should be reviewed, and we will do so upon the disposition of Draft Policy 2013-6, regardless of outcome. Thanks! /John John Curran President and CEO ARIN From frnkblk at iname.com Sun Oct 6 00:42:35 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 5 Oct 2013 23:42:35 -0500 Subject: [arin-ppml] ARIN-PPML Digest, Vol 100, Issue 2 In-Reply-To: <1381007085.59696.YahooMailNeo@web124705.mail.ne1.yahoo.com> References: <1381007085.59696.YahooMailNeo@web124705.mail.ne1.yahoo.com> Message-ID: <00ce01cec24e$7a9202b0$6fb60810$@iname.com> If 2013-6 were passed then those who might abuse ARIN's policies for nefarious means might use other RIRs, possibly (likely?) less cooperative in sharing ownership information than ARIN, which is HQ'ed in the U.S. I don't see how 2013-6 helps U.S. LEA's with the identification of netblock owners because it's just going to drive the bad guys away from using ARIN and to use other RIRs. Second, I don't believe a US LEA has more or less authority to track or subpoena the actual traffic, or go after nefarious activity, if they're using non-ARIN address space within the US. A corollary, I don't think if the bad guys used ARIN-assigned address space outside the U.S. that a U.S. LEA will have a greater advantage than if the bad guys used non-ARIN assigned space outside the U.S. Honestly, I don't see how 2013-6 aids U.S. LEA in tracking down or taking down the bad guys. Frank From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of nathalie coupet Sent: Saturday, October 05, 2013 4:05 PM To: arin-ppml at arin.net Cc: jcurran at arin.net Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 100, Issue 2 Hello John, As far as law enforcement agencies are concerned, the problem is not so much a question of depletion of the IPv4 pool but of traceability back to the attacker in case of misuse of the Internet, such as for MitMA or DDoS (many attackers of US websites being located in the APNIC/Middle East Regions). The problem is even more acute for IPv6 addresses, since blocks allocated are larger than those for IPv4. Maybe ARIN's policy should be consistent regarding the allocation of both IPv4 and IPv6 addresses requesting that stakeholders have sufficient attachment to the region prior to receiving IP addresses from ARIN. If we do not take into consideration security concerns into our own hands and decide for ourselves what we tolerate and what we don't, others will enact rules and procedures that might end up affecting the organization in a way that could really detrimental to business. Nathalie Coupet ARIN Member _____ From: "arin-ppml-request at arin.net " > To: arin-ppml at arin.net Sent: Friday, October 4, 2013 7:32 PM Subject: ARIN-PPML Digest, Vol 100, Issue 2 Send ARIN-PPML mailing list submissions to arin-ppml at arin.net To subscribe or unsubscribe via the World Wide Web, visit http://lists.arin.net/mailman/listinfo/arin-ppml or, via email, send a message with subject or body 'help' to arin-ppml-request at arin.net You can reach the person managing the list at arin-ppml-owner at arin.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ARIN-PPML digest..." Today's Topics: 1. Re: Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised (John Curran) 2. Out-of-region overreaction? (Frank Bulk) 3. Re: Out-of-region overreaction? (Scott Leibrand) 4. Re: Out-of-region overreaction? (Jimmy Hess) ---------------------------------------------------------------------- Message: 1 Date: Fri, 4 Oct 2013 19:55:59 +0000 From: John Curran > To: Gary Buhrmaster > Cc: "arin-ppml at arin.net " > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised Message-ID: <42C9B415-75DB-4AB7-955F-BD84AB9C64EC at arin.net > Content-Type: text/plain; charset="us-ascii" Gary - Since June 2013, there have been 52 requests that would not have been approved under the new policy because these organizations had only some equipment in a data center in the ARIN region, but either all or most of their technical infrastructure outside of the region and most or all of their customers outside of the ARIN region. Total amount of space issued to these 52 organizations: 9,672 /24s, (which is a bit more than a /11 in total) and nearly all organizations were based in the APNIC region. FYI, /John John Curran President and CEO ARIN > On Sep 27, 2013, at 11:37 PM, John Curran > wrote: > >> On Sep 26, 2013, at 3:06 PM, Gary Buhrmaster > wrote: >> >>> On Thu, Sep 26, 2013 at 6:21 PM, John Curran > wrote: >>> ... >>> That is correct (and reflects current practice handling resource requests.) >> >> John, >> >> I support the policy, but I do have a few questions that >> would help finalize my thinking (that I do not recall seeing >> asked or answered). I understand that any answers are >> going to be more WAGs than facts, and you may not >> have the information or ability to provide the answers, >> but any answers would help me (and perhaps others) >> recognize the implications of such a change (if any)? >> I'll accept as many additional caveats you want to add >> to any response. >> >> * If this policy was in place for (say) the last year, what >> is the order of magnitude of number of requests that >> would have been referred to another RIR (1, 10, 100, 1000)? >> >> * If this policy was in place for (say) the last year, can >> you break down the requests by the RIR that the >> requester appeared to be have their plurality? >> >> * If this policy was in place for (say) the last year, what >> is the order of magnitude of the IPv4 numbers that >> would not have been issued by ARIN (/24 ... /8)? > > Gary - > > We're looking into your concerns, and will see whether we > can provide any insights/WAGs can be provided regarding > the potential impact of the policy (as compared to past > requests.) > > Thanks for the thought-provoking questions! > /John > > John Curran > President and CEO > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. ------------------------------ Message: 2 Date: Fri, 4 Oct 2013 15:31:32 -0500 From: "Frank Bulk" > To: > Subject: [arin-ppml] Out-of-region overreaction? Message-ID: <00ef01cec140$b6ccb5e0$246621a0$@iname.com > Content-Type: text/plain; charset="iso-8859-1" I was requesting some ISP IPv6 space and the kindly ARIN staff posted this in their response: Please reply and verify that you will be using the requested number resources within the ARIN region and announcing all routing prefixes of the requested space from within the ARIN region. In accordance with section 2.2 of the NRPM, ARIN issues number resources only for use within its region. ARIN is therefore only able to provide for your in-region numbering needs.? I'm familiar with the concern about out-of-region folk taking advantage of ARIN's current IPv4 supply, but I have a few concerns about the wording of the staff communication. a) It's been my understanding thus far that if I'm an ISP that provides service in multiple places around the world that I may divide my allocation into smaller prefixes and advertise those to area peers. It seems ARIN staff would preclude me from doing any of that. "All" is a pretty strong word, and if ARIN really believes it, a lot of violators could be found. b) It seems that Section 2.2 of the NRPM is being misapplied. 2.2. Regional Internet Registry (RIR) Regional Internet Registries (RIRs) are established and authorized by respective regional communities, and recognized by the IANA to serve and represent large geographical regions. The primary role of RIRs is to manage and distribute public Internet address space within their respective regions. While ARIN does issue numbers within its region, section 2.2 does not say "only for use". If an "only" had be applied, I would suggest that it's "only manage and distribute". If I could be so bold, I'd suggest ARIN to use language something along these lines in their communications: Please reply and verify that you will be using the requested number resources primarily within the ARIN region and announcing the majority of routing prefixes of the requested space from within the ARIN region. In accordance with section 2.2 of the NRPM, ARIN issues number resources within its region. Frank ------------------------------ Message: 3 Date: Fri, 4 Oct 2013 14:42:50 -0700 From: Scott Leibrand > To: Frank Bulk > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Out-of-region overreaction? Message-ID: > Content-Type: text/plain; charset="iso-8859-1" Agreed. IMO this is *not* was intended by current policy, *particularly* IPv6 policy. If you get a /32, there's no reason you shouldn't be able to use it globally. Thanks for bringing this up. I think we're going to have a lively discussion next week in Phoenix. :-) -Scott On Fri, Oct 4, 2013 at 1:31 PM, Frank Bulk > wrote: > I was requesting some ISP IPv6 space and the kindly ARIN staff posted this > in their response: > > Please reply and verify that you will be using > the requested number resources within the ARIN region > and announcing all routing prefixes of the requested > space from within the ARIN region. In accordance with > section 2.2 of the NRPM, ARIN issues number resources > only for use within its region. ARIN is therefore only > able to provide for your in-region numbering needs. > > I'm familiar with the concern about out-of-region folk taking advantage of > ARIN's current IPv4 supply, but I have a few concerns about the wording of > the staff communication. > > a) It's been my understanding thus far that if I'm an ISP that provides > service in multiple places around the world that I may divide my allocation > into smaller prefixes and advertise those to area peers. It seems ARIN > staff would preclude me from doing any of that. "All" is a pretty strong > word, and if ARIN really believes it, a lot of violators could be found. > > b) It seems that Section 2.2 of the NRPM is being misapplied. > 2.2. Regional Internet Registry (RIR) > > Regional Internet Registries (RIRs) are established and > authorized by respective regional communities, and > recognized by the IANA to serve and represent large > geographical regions. The primary role of RIRs is to > manage and distribute public Internet address space > within their respective regions. > > While ARIN does issue numbers within its region, section 2.2 does not say > "only for use". If an "only" had be applied, I would suggest that it's > "only manage and distribute". > > If I could be so bold, I'd suggest ARIN to use language something along > these lines in their communications: > > Please reply and verify that you will be using > the requested number resources primarily within the > ARIN region and announcing the majority of routing prefixes > of the requested space from within the ARIN region. > In accordance with section 2.2 of the NRPM, ARIN issues > number resources within its region. > > Frank > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Fri, 4 Oct 2013 18:25:16 -0500 From: Jimmy Hess > To: Frank Bulk > Cc: "arin-ppml at arin.net " > Subject: Re: [arin-ppml] Out-of-region overreaction? Message-ID: > Content-Type: text/plain; charset="iso-8859-1" On Fri, Oct 4, 2013 at 3:31 PM, Frank Bulk > wrote: > > I'm familiar with the concern about out-of-region folk taking advantage of > ARIN's current IPv4 supply, but I have a few concerns about the wording of > the staff communication. > > a) It's been my understanding thus far that if I'm an ISP that provides > service in multiple places around the world that I may divide my allocation > into smaller prefixes and advertise those to area peers. It seems ARIN > No. You can subdelegate portions of your allocation to customers. Your upstreams are not going to necessarily let you pick apart your allocation and advertise every /29; Although ARIN staff should have no objections to this, if your upstreams will allow it, and you show that to be the case. If you are chopping up your block; you do not need a big allocation from ARIN, though, of sufficient size for all your regions. It only makes sense if you intend to keep your block _whole_; and advertise a single block in multiple regions. If you intend to chop up your blocks anyways; then a sensible thing to do is to obtain multiple blocks instead -- from the appropriate regions where they will be used. > staff would preclude me from doing any of that. "All" is a pretty strong > word, and if ARIN really believes it, a lot of violators could be found. > Routing is out of scope of ARIN policy in the first place; you have an option of not advertising your allocation at all. You are allowed to have a privately interconnected network that spans regions. ARIN staff can reject your verification justification for the allocation; if you don't show you have an intention to use a significant amount of resources in the ARIN region While ARIN does issue numbers within its region, section 2.2 does not say > "only for use". If an "only" had be applied, I would suggest that it's > "only manage and distribute". > Policy does not say "only for use"; however there is not policy specifically encouraging ARIN to recognize use outside of the ARIN region. It is not sufficient for use to merely be "allowed"; ARIN has to have procedures for validating and auditing the use. It is possible, that you may be allowed to use out of region, but not be able to cite your out of region networks requirements as justification for obtaining a larger block than if your out-of-region usage did not exist at all, or it may not be accepted as current use to satisfy utilization requirement for a future allocation. > If I could be so bold, I'd suggest ARIN to use language something along > these lines in their communications: > > Please reply and verify that you will be using > the requested number resources primarily within the > ARIN region and announcing the majority of routing prefixes > of the requested space from within the ARIN region. > In accordance with section 2.2 of the NRPM, ARIN issues > number resources within its region. > > This is very similar to the original quote of what they had said....... > Frank > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml End of ARIN-PPML Digest, Vol 100, Issue 2 ***************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sun Oct 6 08:38:14 2013 From: bill at herrin.us (William Herrin) Date: Sun, 6 Oct 2013 08:38:14 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> Message-ID: On Sun, Oct 6, 2013 at 12:20 AM, John Curran wrote: > On Oct 5, 2013, at 3:53 PM, William Herrin wrote: > >> On Fri, Oct 4, 2013 at 3:55 PM, John Curran wrote: >>> Since June 2013, there have been 52 requests that would not have >>> been approved under the new policy because these organizations >>> had only some equipment in a data center in the ARIN region, but >>> either all or most of their technical infrastructure outside of the region >>> and most or all of their customers outside of the ARIN region. >>> >>> Total amount of space issued to these 52 organizations: 9,672 /24s, >>> (which is a bit more than a /11 in total) and nearly all organizations were based in the APNIC region. >> >> Hi John, >> >> I notice from Frank Bulk's thread that ARIN has instituted a change in >> procedure for address allocation related to in-region use. Were the >> new procedures in place, how would that have impacted the 52 requests >> you reference? > > Bill - > > ARIN's procedures for requesters has not changed since the Policy > Implementation and Experience Report addressing this topic (at the > ARIN 31 meeting in Bridgetown); hence, the 52 requests would still > be processed. As noted earlier to Frank, I believe that the text > sent in response should be reviewed, and we will do so upon the > disposition of Draft Policy 2013-6, regardless of outcome. Hi John, To be clear, ARIN sent the following text (as quoted by Frank) to the above 52 requestors and they replied in the affirmative? Please reply and verify that you will be using the requested number resources within the ARIN region and announcing all routing prefixes of the requested space from within the ARIN region. In accordance with section 2.2 of the NRPM, ARIN issues number resources only for use within its region. ARIN is therefore only able to provide for your in-region numbering needs. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jcurran at arin.net Sun Oct 6 08:53:34 2013 From: jcurran at arin.net (John Curran) Date: Sun, 6 Oct 2013 12:53:34 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> Message-ID: <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> On Oct 6, 2013, at 5:38 AM, William Herrin wrote: > To be clear, ARIN sent the following text (as quoted by Frank) to the > above 52 requestors and they replied in the affirmative? Bill - ARIN does not disclose requests received for number resources management. To provide some insight, however, organizations often reference NRPM (and assert compliance with the policy therein) when their interpretation is different from that of the staff implementation. While staff tries to be true to the language (and the spirit) of number resource policy as adopted, diligent requesters who have a credible claim of compliance to NRPM are approved. Recurring situations with particular policy text or implementation frequently have the honor being reported back at the next Policy Implementation and Experience Report so that the community can consider these cases and have the option of providing clearer policy guidance. Thanks! /John John Curran President and CEO ARIN From bill at herrin.us Sun Oct 6 11:31:44 2013 From: bill at herrin.us (William Herrin) Date: Sun, 6 Oct 2013 11:31:44 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> Message-ID: On Sun, Oct 6, 2013 at 8:38 AM, William Herrin wrote: > On Sun, Oct 6, 2013 at 12:20 AM, John Curran wrote: >> On Oct 5, 2013, at 3:53 PM, William Herrin wrote: >> >>> On Fri, Oct 4, 2013 at 3:55 PM, John Curran wrote: >>>> Since June 2013, there have been 52 requests that would not have >>>> been approved under the new policy because these organizations >>>> had only some equipment in a data center in the ARIN region, but >>>> either all or most of their technical infrastructure outside of the region >>>> and most or all of their customers outside of the ARIN region. >> ARIN's procedures for requesters has not changed since the Policy >> Implementation and Experience Report addressing this topic (at the >> ARIN 31 meeting in Bridgetown [April 2013 -- Bill]); hence, the 52 >> requests would still >> be processed. As noted earlier to Frank, I believe that the text >> sent in response should be reviewed, and we will do so upon the >> disposition of Draft Policy 2013-6, regardless of outcome. > > To be clear, ARIN sent the following text (as quoted by Frank) to the > above 52 requestors and they replied in the affirmative? > > Please reply and verify that you will be using > the requested number resources within the ARIN region > and announcing all routing prefixes of the requested > space from within the ARIN region. In accordance with > section 2.2 of the NRPM, ARIN issues number resources > only for use within its region. ARIN is therefore only > able to provide for your in-region numbering needs. On Sun, Oct 6, 2013 at 8:53 AM, John Curran wrote: > ARIN does not disclose requests received for number resources > management. You just did, John. You just reported that 52 requests were filled which would not have been under the draft policy. There you are doing it in the quotes above. > To provide some insight, however, organizations often reference > NRPM (and assert compliance with the policy therein) when their > interpretation is different from that of the staff implementation. > > While staff tries to be true to the language (and the spirit) of > number resource policy as adopted, diligent requesters who have > a credible claim of compliance to NRPM are approved. It's an simple question John. Please stop ducking it. You reported that 52 organizations received addresses from ARIN although "all or most" of their infrastructure and customers were outside the ARIN region. You stated that the reported message (demanding certification that the infrastructure be in-region) was part of ARIN's procedures throughout the time period in which the 52 requests were honored. What gives? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jcurran at arin.net Sun Oct 6 11:57:58 2013 From: jcurran at arin.net (John Curran) Date: Sun, 6 Oct 2013 15:57:58 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> Message-ID: <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> On Oct 6, 2013, at 8:31 AM, William Herrin wrote: > You reported that 52 organizations received addresses from ARIN > although "all or most" of their infrastructure and customers were > outside the ARIN region. That is correct. > You stated that the reported message (demanding certification that the > infrastructure be in-region) was part of ARIN's procedures throughout > the time period in which the 52 requests were honored. Bill - ARIN's current procedures have requesters "verify that you will be using the requested number resources within the ARIN region and announcing all routing prefixes of the requested space from within the ARIN region." All 52 requesters verified the above. There is frequently discussion of the term "use in region" (just as raised in Frank Bulk's email). As noted in the policy experience report, the "use" of the addresses within ARIN region is often accomplished via nominal hosted infrastructure within the ARIN region, despite being driven by customers predominantly outside of the ARIN region. See pages 9 through 14 of the referenced ARIN 31 Policy Implementation and Experience Report for details, and do not hesitate to contact me here (or via jcurran at arin.net directly) if you have questions - We report policy experiences such as this one so that the community can consider whether changes to policy language are warranted, and that can either be to change the intent of the policy, or policy changes to make clearer the present intent and hence drive better implementation. Thanks! /John John Curran President and CEO ARIN From hannigan at gmail.com Sun Oct 6 14:10:36 2013 From: hannigan at gmail.com (Martin Hannigan) Date: Sun, 6 Oct 2013 14:10:36 -0400 Subject: [arin-ppml] Out-of-region overreaction? In-Reply-To: <5250AC1F.6070603@umn.edu> References: <00ef01cec140$b6ccb5e0$246621a0$@iname.com> <5250AC1F.6070603@umn.edu> Message-ID: On Sat, Oct 5, 2013 at 8:17 PM, David Farmer wrote: > On 10/4/13 15:31 , Frank Bulk wrote: > >> I was requesting some ISP IPv6 space and the kindly ARIN staff posted this >> in their response: >> >> Please reply and verify that you will be using >> the requested number resources within the ARIN region >> and announcing all routing prefixes of the requested >> space from within the ARIN region. In accordance with >> section 2.2 of the NRPM, ARIN issues number resources >> only for use within its region. ARIN is therefore only >> able to provide for your in-region numbering needs. >> >> I'm familiar with the concern about out-of-region folk taking advantage of >> ARIN's current IPv4 supply, but I have a few concerns about the wording of >> the staff communication. >> >> a) It's been my understanding thus far that if I'm an ISP that provides >> service in multiple places around the world that I may divide my >> allocation >> into smaller prefixes and advertise those to area peers. It seems ARIN >> staff would preclude me from doing any of that. "All" is a pretty strong >> word, and if ARIN really believes it, a lot of violators could be found. >> >> b) It seems that Section 2.2 of the NRPM is being misapplied. >> 2.2. Regional Internet Registry (RIR) >> >> Regional Internet Registries (RIRs) are established and >> authorized by respective regional communities, and >> recognized by the IANA to serve and represent large >> geographical regions. The primary role of RIRs is to >> manage and distribute public Internet address space >> within their respective regions. >> >> While ARIN does issue numbers within its region, section 2.2 does not say >> "only for use". If an "only" had be applied, I would suggest that it's >> "only manage and distribute". >> >> If I could be so bold, I'd suggest ARIN to use language something along >> these lines in their communications: >> >> Please reply and verify that you will be using >> the requested number resources primarily within the >> ARIN region and announcing the majority of routing prefixes >> of the requested space from within the ARIN region. >> In accordance with section 2.2 of the NRPM, ARIN issues >> number resources within its region. >> >> Frank >> > > Staff has called out this issue several times in the past couple years, > and the community has failed to provide any guidance via policy several > times. That's nice, but perhaps we don't want them to do anything even if they want to? That's why we repeatedly reject proposals such as this and others that typically are attempted to be wedged in under Section 12. This may as well be one of those. ARIN already has the power to do the right thing if they thing that there are nefarious activities happening and they can also validate subscribed information to their hearts content. Feel free to explain the problem again? I am +1, this is an over reaction. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sun Oct 6 18:22:54 2013 From: bill at herrin.us (William Herrin) Date: Sun, 6 Oct 2013 18:22:54 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> Message-ID: On Sun, Oct 6, 2013 at 11:57 AM, John Curran wrote: > On Oct 6, 2013, at 8:31 AM, William Herrin wrote: >> You stated that the reported message (demanding certification that the >> infrastructure be in-region) was part of ARIN's procedures throughout >> the time period in which the 52 requests were honored. > > ARIN's current procedures have requesters "verify that you will be using > the requested number resources within the ARIN region and announcing all > routing prefixes of the requested space from within the ARIN region." > > All 52 requesters verified the above. There is frequently discussion of > the term "use in region" (just as raised in Frank Bulk's email). As noted > in the policy experience report, the "use" of the addresses within ARIN > region is often accomplished via nominal hosted infrastructure within the > ARIN region Hi John, There is a subtlety here that is escaping me. If the addresses are assigned to hosted infrastructure within the region then how are they not used within the region? What aspect of the draft policy would change that evaluation? If the addresses aren't assigned to hosted infrastructure within the region then how are they "used" within the region? It seems to me that one would have to pull a Clinton on the word "used" ("It depends on what the meaning of the word 'is' is.") before addresses assigned to equipment elsewhere would be considered used within the region. > See pages 9 through 14 of the referenced ARIN 31 Policy > Implementation and Experience Report for details "Should we continue with current practice or should we make decisions based on where the customers and the equipment serving those customers are located?" An IP address has a physical location: it matches the equipment which identifies itself using that IP address. Within the caveat that subnets are used on layer-2 networks and a long-haul layer-2 network may span two regions, is this not the current practice? It just doesn't seem like a concept that's open to a terribly broad set of interpretations. As for making the decision based on where the customers are located, that would strike me as untenable. A web server is at a specific location but a web site has customers which span the world. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From drc at virtualized.org Sun Oct 6 18:33:48 2013 From: drc at virtualized.org (David Conrad) Date: Sun, 6 Oct 2013 15:33:48 -0700 Subject: [arin-ppml] ARIN-PPML Digest, Vol 100, Issue 2 In-Reply-To: <00ce01cec24e$7a9202b0$6fb60810$@iname.com> References: <1381007085.59696.YahooMailNeo@web124705.mail.ne1.yahoo.com> <00ce01cec24e$7a9202b0$6fb60810$@iname.com> Message-ID: <094FEF92-6CB7-4D57-A5F7-219EB0920F4E@virtualized.org> Frank, On Oct 5, 2013, at 9:42 PM, Frank Bulk wrote: > If 2013-6 were passed then those who might abuse ARIN?s policies for nefarious means might use other RIRs, possibly (likely?) less cooperative in sharing ownership information than ARIN, which is HQ?ed in the U.S. My understanding is that the reason this issue has been raised (at least from ARIN staff's perspective) is that folks from the AP region are obtaining address space from ARIN because it was easier than obtaining the addresses from LACNIC/AfriNIC. My impression is that the real value in this policy proposal is to level the playing field, that is, to make the level of difficulty in obtaining out-of-region address space that same across all the RIRs that still have space. > Honestly, I don?t see how 2013-6 aids U.S. LEA in tracking down or taking down the bad guys. LEA folks seem to feel otherwise. It's unfortunate that the current stupidity in DC is preventing Terri or others from explaining why (and I don't have sufficient information to argue one way or the other). However, I believe the primary point of the policy is to give ARIN staff official backing to revoke address space when they notice/are notified that the address space is being used out of region. The interests of LEA (and anti-spam/anti-phishing/etc. folks IIUC) are a bit orthogonal, even if it was LEA interests that generated the policy proposal (this time). Regards, -drc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mysidia at gmail.com Sun Oct 6 18:48:53 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 6 Oct 2013 17:48:53 -0500 Subject: [arin-ppml] ARIN-PPML Digest, Vol 100, Issue 2 Message-ID: On Sun, Oct 6, 2013 at 5:33 PM, David Conrad wrote: > On Oct 5, 2013, at 9:42 PM, Frank Bulk wrote: > My understanding is that the reason this issue has been raised (at least > from ARIN staff's perspective) is that folks from the AP region are > obtaining address space from ARIN because it was easier than obtaining the > addresses from LACNIC/AfriNIC. > That's interesting. Especially since AfriNIC has more IPv4 free pool than ARIN, and ARIN should certainly not be supplementing this, until such time as their remaining IPv4 is a small number of /8 equivalents than in ARIN free pool..... > However, I believe the primary point of the policy is to give ARIN staff > official backing to revoke address space when they notice/are notified that > the address space is being used out of region. The interests of LEA (and > anti-spam/anti-phishing/etc. folks IIUC) are a bit orthogonal, even if it > was LEA interests that generated the policy proposal (this time). > I would say no..... it should give no backing for revokation, unless the applicant committed a fraud, by lying to ARIN staff, or submitting an application under false pretense regarding the use of the IP numbers. In which case, the allocation could be revoked anyways. I would like to propose an addendum to the ARIN RSA agreement in conjunction with the policy, in that case: CHANGE "(i) ARIN will take no action to reduce the Services currently provided for Included Number Resources due to lack of utilization by the Holder, and (ii) ARIN has no right to revoke any Included Number Resources under this Agreement due to lack of utilization by Holder." TO "(i) ARIN will take no action to reduce the Services currently provided for Included Number Resources due to lack of utilization by the Holder, or utilization of resources outside the ARIN region, and (ii) ARIN has no right to revoke any Included Number Resources under this Agreement due to lack of utilization by Holder, or utilization of number resources outside the ARIN region." -- -JH -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Oct 7 08:53:51 2013 From: jcurran at arin.net (John Curran) Date: Mon, 7 Oct 2013 12:53:51 +0000 Subject: [arin-ppml] Out-of-region overreaction? In-Reply-To: References: <00ef01cec140$b6ccb5e0$246621a0$@iname.com> <5250AC1F.6070603@umn.edu> Message-ID: On Oct 6, 2013, at 11:10 AM, Martin Hannigan > wrote: On Sat, Oct 5, 2013 at 8:17 PM, David Farmer > wrote: ... Staff has called out this issue several times in the past couple years, and the community has failed to provide any guidance via policy several times. That's nice, but perhaps we don't want them to do anything even if they want to? To be clear, the staff does not "want" to do anything, per se, with the present policy - the Policy Implementation and Experience Report is meant to highlight aspects of deployed policy that the community might not be aware of or may have challenges in implementation; this allows policy changes to be considered if the current policy behavior doesn't match the community expectations. Of course, there is a preference for clearer policy, but as long as the community is aware of (and can accept) the implications of the existing address policy then the existing policy language is fine. With the report, we are simply raising the awareness of any implications that may not be obvious or may be a source of contention when processing resources requests. ARIN already has the power to do the right thing if they thing that there are nefarious activities happening and they can also validate subscribed information to their hearts content. You are correct - ARIN has adequate provisions in the NRPM to investigate issues of fraudulent requests, and that is not the case here; the resources being requested from ARIN (for the servicing customers almost entirely out of region) is within current policy, even if the result may not match expectations of some in the community. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Oct 7 11:37:42 2013 From: jcurran at arin.net (John Curran) Date: Mon, 7 Oct 2013 15:37:42 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> Message-ID: <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> On Oct 6, 2013, at 3:22 PM, William Herrin wrote: > There is a subtlety here that is escaping me. If the addresses are > assigned to hosted infrastructure within the region then how are they > not used within the region? Bill - Apologies in advance for length - the community is entitled to a complete understanding of how we administer number resources, and that appears to take more words than I expected at first.. Technical infrastructure can be used to justify addresses (for example, network routers, POP equipment, concentrators, management systems, IT systems, data center servers, etc.) We're very experienced with this, and often ask for equipment lists, invoices, etc. to confirm existence of the asserted equipment. When technical infrastructure grows, more IP addresses are needed for assignment to the technical infrastructure. Technical infrastructure exists in a region based on the location of the physical devices. Customers growth can also justify addresses (e.g. you assign addresses to an single customer, or customer growth requires that a certain dynamic pool assigned to customers be expanded) We are also quite experienced with the verification of customers, including obtaining customer lists, contact info, etc. When the number of customers served grows, more IP addresses are needed to assign to the new customers, or to assign to the dynamic pools for those customers. Customers exist in a region, based on their actual location of each customer. For example, if someone needs more addresses because they are adding new VPN concentrators (i.e. more actual equipment itself), then that is indeed technical infrastructure need based on where the equipment will be installed. i.e. if you buy stacks of new VPN concentrators and have no addresses to connect them to your infrastructure, it's a simple matter to request (per policy) additional addresses needed. We do this all of the time with the infrastructure side of DSLAMS, cable head-ends, wifi nodes, etc. If someone needs additional addresses for their _customers_ (including to expand a dynamically assigned pool), then we verify the customer growth as noted earlier, including the location of the customers. Requesters have to show that they have additional equipment or additional customers to obtain addition addresses. Both equipment and customers are associated with real-world addresses, and hence are within some region of the registry system. > What aspect of the draft policy would change that evaluation? ... The draft policy 2013-6 reads as follows: "In addition to meeting all other applicable policy requirements, a plurality of new resources requested from ARIN must be justified by technical infrastructure or customers located within the ARIN service region, and any located outside the region must be interconnected to the ARIN service region." The requesters who were previously discussed (i.e. "the 52" who have received allocations since mid-year), often have some existing infrastructure, are not adding anything more, and do not need more addresses due to their _technical infrastructure_ growth. They do have remarkable customer growth, and hence need additional addresses. Under the policy change proposed by 2013-6, we would only consider customers within the ARIN service region for this purpose, and would provide an allocation which they could justify based on that in-region customer demand. The proposed policy change makes clear that customers must be in-region to be considered. (The present policy does not have such a constraint, hence the approval of recent requests where the vast majority of customers are known to be outside the ARIN region.) We don't consider virtual "technical infrastructure" for assessing the need for addresses, even though service providers may use such when adding customers. The additional customers driving such virtual growth are readily verifiable. The alternative would be to consider virtual equipment (e.g. VM's) as actual technical infrastructure and that would effectively open the justification of unlimited resources by any party without any actual equipment or customer growth. If the desire was to simply clarify existing policy (without actually changing the current practice), it could be accomplished by dropping the "in region" requirement for customers as follows: "must be justified by technical infrastructure within the ARIN or by customers located anywhere as long as the addresses are managed and interconnected in the ARIN service region." (Note that such a change would make rather clear that nearly any heavily-utilized customer-driven IP address pool interconnected in the ARIN region can qualify for additional resources, which may or may not be a desirable outcome depending on one's individual perspective.) I hope this helps in clarifying what ARIN-2013-6 would be change to the existing policy, as it would make clear that customer growth in-region would be necessary to justify requests, whereas presently we have some folks requesting resources using nominal equipment within the region and backed by extensive customer growth external to the region. Please do not hesitate to ask if you have any further questions - it is indeed very important that folks understand how we implement the policy in order to fully consider any proposed policy changes, so thank you for your diligence on this topic. /John John Curran President and CEO ARIN From info at arin.net Mon Oct 7 17:49:17 2013 From: info at arin.net (ARIN) Date: Mon, 07 Oct 2013 17:49:17 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - September 2013 In-Reply-To: <5241C41B.4060300@arin.net> References: <5241C41B.4060300@arin.net> Message-ID: <52532C5D.2020204@arin.net> >> The AC abandoned ARIN-2013-5. Anyone dissatisfied with this decision may >> initiate a petition. The deadline to begin a petition will be five >> business days after the AC's draft meeting minutes are published. The minutes of the AC's 19 September 2013 meeting have been published and are available at: https://www.arin.net/about_us/ac/ac2013_0919.html The deadline to begin a petition is 12 October 2013. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 9/24/13 12:55 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process, the ARIN > Advisory Council (AC) held a meeting on 19 September 2013 and made > decisions about draft policies. > > Having found the following draft policy to be fully developed and > meeting ARIN's Principles of Internet Number Resource Policy, the AC > recommended it for adoption. This draft policy will be posted shortly > for discussion on the Public Policy Mailing List as a Recommended Draft > Policy. > > Draft Policy ARIN-2013-4: RIR Principles > > The AC is continuing to work on the following: > > Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to > Out-of-region Requestors > Draft Policy ARIN-2013-7: Merge IPv4 ISP and End-User Requirements > > 2013-4, 2013-6 and 2013-7 will be presented at the upcoming ARIN Public > Policy Consultation at NANOG 59 and the ARIN 32 Public Policy Meeting in > Phoenix. > > The AC abandoned the following: > > Draft Policy ARIN-2013-5: LIR/ISP and End-user Definitions > > The AC provided this statement about 2013-5: > "The ARIN Advisory Council voted to abandon ARIN 2013-5 "2013-5 LIR/ISP > and End-user Definitions". The AC feels that based on community > feedback, the proposal would not be able to reach consensus. In > addition, the original and revised text were not able to solve the > problem that the author intended." > > The AC abandoned ARIN-2013-5. Anyone dissatisfied with this decision may > initiate a petition. The deadline to begin a petition will be five > business days after the AC's draft meeting minutes are published. For > more information on starting and participating in petitions, see PDP > Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > Draft Policy and Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) From frnkblk at iname.com Tue Oct 8 12:26:32 2013 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 8 Oct 2013 11:26:32 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> Message-ID: <000d01cec443$2666b040$733410c0$@iname.com> John, What if Acme Hosting, Inc., located in the Silicon Valley, found a niche offering virtualized servers for Asian customers who want to have their Internet-based services hosted more closely to the North American market. Acme Hosting and their infrastructure are clearly in the U.S., but their customers are not in the ARIN region. Does the policy, as currently written, preclude Acme Hosting from requesting more address space as their Asian customer base grows? Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Monday, October 07, 2013 10:38 AM To: William Herrin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised Under the policy change proposed by 2013-6, we would only consider customers within the ARIN service region for this purpose, and would provide an allocation which they could justify based on that in-region customer demand. The proposed policy change makes clear that customers must be in-region to be considered. (The present policy does not have such a constraint, hence the approval of recent requests where the vast majority of customers are known to be outside the ARIN region.) We don't consider virtual "technical infrastructure" for assessing the need for addresses, even though service providers may use such when adding customers. The additional customers driving such virtual growth are readily verifiable. The alternative would be to consider virtual equipment (e.g. VM's) as actual technical infrastructure and that would effectively open the justification of unlimited resources by any party without any actual equipment or customer growth. /John John Curran President and CEO 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From owen at delong.com Tue Oct 8 13:04:41 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Oct 2013 10:04:41 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <000d01cec443$2666b040$733410c0$@iname.com> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> Message-ID: <375C3B8D-ADD7-4EDD-9645-8EA9A8FFDED6@delong.com> Neither current ARIN policy, nor proposal 2013-6 would preclude that request for addresses, IMHO. Owen On Oct 8, 2013, at 9:26 AM, "Frank Bulk" wrote: > John, > > What if Acme Hosting, Inc., located in the Silicon Valley, found a niche > offering virtualized servers for Asian customers who want to have their > Internet-based services hosted more closely to the North American market. > > Acme Hosting and their infrastructure are clearly in the U.S., but their > customers are not in the ARIN region. > > Does the policy, as currently written, preclude Acme Hosting from requesting > more address space as their Asian customer base grows? > > Frank > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of John Curran > Sent: Monday, October 07, 2013 10:38 AM > To: William Herrin > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and > IPv6 Address Space to Out-of-region Requestors - Revised > > > > Under the policy change proposed by 2013-6, we would only consider customers > > within the ARIN service region for this purpose, and would provide an > allocation > which they could justify based on that in-region customer demand. The > proposed > policy change makes clear that customers must be in-region to be considered. > > (The present policy does not have such a constraint, hence the approval of > recent requests where the vast majority of customers are known to be outside > > the ARIN region.) > > We don't consider virtual "technical infrastructure" for assessing the need > for addresses, even though service providers may use such when adding > customers. > The additional customers driving such virtual growth are readily verifiable. > > The alternative would be to consider virtual equipment (e.g. VM's) as actual > > technical infrastructure and that would effectively open the justification > of > unlimited resources by any party without any actual equipment or customer > growth. > > > > /John > > John Curran > President and CEO > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Tue Oct 8 13:06:36 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Oct 2013 10:06:36 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> Message-ID: <7C8FD027-9205-49CF-9367-49F04AB4DCE5@delong.com> Perhaps replacing "technical infrastructure" with "addresses assigned to equipment and/or interfaces physically present within the ARIN region". Owen On Oct 7, 2013, at 8:37 AM, John Curran wrote: > On Oct 6, 2013, at 3:22 PM, William Herrin wrote: > >> There is a subtlety here that is escaping me. If the addresses are >> assigned to hosted infrastructure within the region then how are they >> not used within the region? > > Bill - > > Apologies in advance for length - the community is entitled to a complete > understanding of how we administer number resources, and that appears to > take more words than I expected at first.. > > Technical infrastructure can be used to justify addresses (for example, > network routers, POP equipment, concentrators, management systems, IT > systems, data center servers, etc.) We're very experienced with this, > and often ask for equipment lists, invoices, etc. to confirm existence > of the asserted equipment. > > When technical infrastructure grows, more IP addresses are needed for > assignment to the technical infrastructure. Technical infrastructure > exists in a region based on the location of the physical devices. > > Customers growth can also justify addresses (e.g. you assign addresses to > an single customer, or customer growth requires that a certain dynamic pool > assigned to customers be expanded) We are also quite experienced with the > verification of customers, including obtaining customer lists, contact info, > etc. > > When the number of customers served grows, more IP addresses are needed to > assign to the new customers, or to assign to the dynamic pools for those > customers. Customers exist in a region, based on their actual location of > each customer. > > For example, if someone needs more addresses because they are adding > new VPN concentrators (i.e. more actual equipment itself), then that is > indeed technical infrastructure need based on where the equipment will > be installed. i.e. if you buy stacks of new VPN concentrators and have > no addresses to connect them to your infrastructure, it's a simple matter > to request (per policy) additional addresses needed. We do this all of > the time with the infrastructure side of DSLAMS, cable head-ends, wifi > nodes, etc. > > If someone needs additional addresses for their _customers_ (including > to expand a dynamically assigned pool), then we verify the customer > growth as noted earlier, including the location of the customers. > > Requesters have to show that they have additional equipment or additional > customers to obtain addition addresses. Both equipment and customers are > associated with real-world addresses, and hence are within some region of > the registry system. > >> What aspect of the draft policy would change that evaluation? ... > > The draft policy 2013-6 reads as follows: > > "In addition to meeting all other applicable policy requirements, > a plurality of new resources requested from ARIN must be justified > by technical infrastructure or customers located within the ARIN > service region, and any located outside the region must be > interconnected to the ARIN service region." > > The requesters who were previously discussed (i.e. "the 52" who have received > allocations since mid-year), often have some existing infrastructure, are not > adding anything more, and do not need more addresses due to their _technical > infrastructure_ growth. > > They do have remarkable customer growth, and hence need additional addresses. > Under the policy change proposed by 2013-6, we would only consider customers > within the ARIN service region for this purpose, and would provide an allocation > which they could justify based on that in-region customer demand. The proposed > policy change makes clear that customers must be in-region to be considered. > (The present policy does not have such a constraint, hence the approval of > recent requests where the vast majority of customers are known to be outside > the ARIN region.) > > We don't consider virtual "technical infrastructure" for assessing the need > for addresses, even though service providers may use such when adding customers. > The additional customers driving such virtual growth are readily verifiable. > The alternative would be to consider virtual equipment (e.g. VM's) as actual > technical infrastructure and that would effectively open the justification of > unlimited resources by any party without any actual equipment or customer growth. > > If the desire was to simply clarify existing policy (without actually changing > the current practice), it could be accomplished by dropping the "in region" > requirement for customers as follows: "must be justified by technical > infrastructure within the ARIN or by customers located anywhere as long as > the addresses are managed and interconnected in the ARIN service region." > (Note that such a change would make rather clear that nearly any heavily-utilized > customer-driven IP address pool interconnected in the ARIN region can qualify > for additional resources, which may or may not be a desirable outcome depending > on one's individual perspective.) > > I hope this helps in clarifying what ARIN-2013-6 would be change to the > existing policy, as it would make clear that customer growth in-region > would be necessary to justify requests, whereas presently we have some > folks requesting resources using nominal equipment within the region and > backed by extensive customer growth external to the region. > > Please do not hesitate to ask if you have any further questions - it is > indeed very important that folks understand how we implement the policy > in order to fully consider any proposed policy changes, so thank you for > your diligence on this topic. > > /John > > John Curran > President and CEO > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jcurran at arin.net Tue Oct 8 13:15:37 2013 From: jcurran at arin.net (John Curran) Date: Tue, 8 Oct 2013 17:15:37 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <000d01cec443$2666b040$733410c0$@iname.com> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> Message-ID: On Oct 8, 2013, at 9:26 AM, Frank Bulk wrote: > John, > > What if Acme Hosting, Inc., located in the Silicon Valley, found a niche > offering virtualized servers for Asian customers who want to have their > Internet-based services hosted more closely to the North American market. > > Acme Hosting and their infrastructure are clearly in the U.S., but their > customers are not in the ARIN region. Their physical infrastructure would only qualify for modest address space in accordance with policy, and this would not change with the addition of virtualized servers on existing equipment. > Does the policy, as currently written, preclude Acme Hosting from requesting > more address space as their Asian customer base grows? Under current policy, they may request additional addresses as their customers grow. Under the current revised policy text, we would not consider their customers who are not in region. This side effect (hosting companies not being able to consider customers who are out of region) may or may not be desirable, but is understandable given the additional of customer region as criteria. FYI, /John John Curran President and CEO ARIN From SRyerse at eclipse-networks.com Tue Oct 8 13:35:11 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 8 Oct 2013 17:35:11 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12013CE81325@ENI-MAIL.eclipse-networks.com> I keep seeing questions going back and forth on this issue. As I understand it two things are trying to be accomplished, first ARIN issued resources are to be primarily used on equipment located within the ARIN region, and second there needs to be some sort of legal presence with contact information in the ARIN region that can be kept in the ARIN database for everyone including law enforcement to access. Can't the policy simply say there must be a legal presence and the resources must be used within the ARIN region, and that resources can be de-allocated if either ceases to be true? The elegance of the Internet is that it can expand an organization's reach - including across RIR boundaries, so who cares if a web server or a virtual server (or whatever) that is physically located in the ARIN region is access by tons of folks outside the region. There just needs to be a legal presence and contact information to go along with that allocation. Trying to apply some test such as majority or plurality will just cause unnecessary complexity and the current policies are complex enough without needlessly adding to it. My 2 cents. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Tuesday, October 08, 2013 1:16 PM To: Frank Bulk Cc: Subject: Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised On Oct 8, 2013, at 9:26 AM, Frank Bulk wrote: > John, > > What if Acme Hosting, Inc., located in the Silicon Valley, found a > niche offering virtualized servers for Asian customers who want to > have their Internet-based services hosted more closely to the North American market. > > Acme Hosting and their infrastructure are clearly in the U.S., but > their customers are not in the ARIN region. Their physical infrastructure would only qualify for modest address space in accordance with policy, and this would not change with the addition of virtualized servers on existing equipment. > Does the policy, as currently written, preclude Acme Hosting from > requesting more address space as their Asian customer base grows? Under current policy, they may request additional addresses as their customers grow. Under the current revised policy text, we would not consider their customers who are not in region. This side effect (hosting companies not being able to consider customers who are out of region) may or may not be desirable, but is understandable given the additional of customer region as criteria. FYI, /John John Curran President and CEO 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From victor.kuarsingh at gmail.com Tue Oct 8 13:45:59 2013 From: victor.kuarsingh at gmail.com (Victor Kuarsingh) Date: Tue, 8 Oct 2013 13:45:59 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <7C8FD027-9205-49CF-9367-49F04AB4DCE5@delong.com> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <7C8FD027-9205-49CF-9367-49F04AB4DCE5@delong.com> Message-ID: Owen, all, I am in agreement, in general, with text that takes that form if this would cover the cases where the use of the addresses would be used on an interfaces, servers, VMs or other elements which are built upon equipment which is present in the ARIN region. regards, Victor K On Tue, Oct 8, 2013 at 1:06 PM, Owen DeLong wrote: > Perhaps replacing "technical infrastructure" with "addresses assigned > to equipment and/or interfaces physically present within the ARIN region". > > Owen > > On Oct 7, 2013, at 8:37 AM, John Curran wrote: > > > On Oct 6, 2013, at 3:22 PM, William Herrin wrote: > > > >> There is a subtlety here that is escaping me. If the addresses are > >> assigned to hosted infrastructure within the region then how are they > >> not used within the region? > > > > Bill - > > > > Apologies in advance for length - the community is entitled to a complete > > understanding of how we administer number resources, and that appears to > > take more words than I expected at first.. > > > > Technical infrastructure can be used to justify addresses (for example, > > network routers, POP equipment, concentrators, management systems, IT > > systems, data center servers, etc.) We're very experienced with this, > > and often ask for equipment lists, invoices, etc. to confirm existence > > of the asserted equipment. > > > > When technical infrastructure grows, more IP addresses are needed for > > assignment to the technical infrastructure. Technical infrastructure > > exists in a region based on the location of the physical devices. > > > > Customers growth can also justify addresses (e.g. you assign addresses to > > an single customer, or customer growth requires that a certain dynamic > pool > > assigned to customers be expanded) We are also quite experienced with > the > > verification of customers, including obtaining customer lists, contact > info, > > etc. > > > > When the number of customers served grows, more IP addresses are needed > to > > assign to the new customers, or to assign to the dynamic pools for those > > customers. Customers exist in a region, based on their actual location > of > > each customer. > > > > For example, if someone needs more addresses because they are adding > > new VPN concentrators (i.e. more actual equipment itself), then that is > > indeed technical infrastructure need based on where the equipment will > > be installed. i.e. if you buy stacks of new VPN concentrators and have > > no addresses to connect them to your infrastructure, it's a simple matter > > to request (per policy) additional addresses needed. We do this all of > > the time with the infrastructure side of DSLAMS, cable head-ends, wifi > > nodes, etc. > > > > If someone needs additional addresses for their _customers_ (including > > to expand a dynamically assigned pool), then we verify the customer > > growth as noted earlier, including the location of the customers. > > > > Requesters have to show that they have additional equipment or additional > > customers to obtain addition addresses. Both equipment and customers are > > associated with real-world addresses, and hence are within some region of > > the registry system. > > > >> What aspect of the draft policy would change that evaluation? ... > > > > The draft policy 2013-6 reads as follows: > > > > "In addition to meeting all other applicable policy requirements, > > a plurality of new resources requested from ARIN must be justified > > by technical infrastructure or customers located within the ARIN > > service region, and any located outside the region must be > > interconnected to the ARIN service region." > > > > The requesters who were previously discussed (i.e. "the 52" who have > received > > allocations since mid-year), often have some existing infrastructure, > are not > > adding anything more, and do not need more addresses due to their > _technical > > infrastructure_ growth. > > > > They do have remarkable customer growth, and hence need additional > addresses. > > Under the policy change proposed by 2013-6, we would only consider > customers > > within the ARIN service region for this purpose, and would provide an > allocation > > which they could justify based on that in-region customer demand. The > proposed > > policy change makes clear that customers must be in-region to be > considered. > > (The present policy does not have such a constraint, hence the approval > of > > recent requests where the vast majority of customers are known to be > outside > > the ARIN region.) > > > > We don't consider virtual "technical infrastructure" for assessing the > need > > for addresses, even though service providers may use such when adding > customers. > > The additional customers driving such virtual growth are readily > verifiable. > > The alternative would be to consider virtual equipment (e.g. VM's) as > actual > > technical infrastructure and that would effectively open the > justification of > > unlimited resources by any party without any actual equipment or > customer growth. > > > > If the desire was to simply clarify existing policy (without actually > changing > > the current practice), it could be accomplished by dropping the "in > region" > > requirement for customers as follows: "must be justified by technical > > infrastructure within the ARIN or by customers located anywhere as long > as > > the addresses are managed and interconnected in the ARIN service region." > > (Note that such a change would make rather clear that nearly any > heavily-utilized > > customer-driven IP address pool interconnected in the ARIN region can > qualify > > for additional resources, which may or may not be a desirable outcome > depending > > on one's individual perspective.) > > > > I hope this helps in clarifying what ARIN-2013-6 would be change to the > > existing policy, as it would make clear that customer growth in-region > > would be necessary to justify requests, whereas presently we have some > > folks requesting resources using nominal equipment within the region and > > backed by extensive customer growth external to the region. > > > > Please do not hesitate to ask if you have any further questions - it is > > indeed very important that folks understand how we implement the policy > > in order to fully consider any proposed policy changes, so thank you for > > your diligence on this topic. > > > > /John > > > > John Curran > > President and CEO > > 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: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Tue Oct 8 13:45:18 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 8 Oct 2013 10:45:18 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12013CE81325@ENI-MAIL.eclipse-networks.com> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> <5B9E90747FA2974D91A54FCFA1B8AD12013CE81325@ENI-MAIL.eclipse-networks.com> Message-ID: Steven, Were you following the discussion at the NANOG PPC? (It's being webcast.) The challenge with what you're describing seems to be that many organizations who provide virtual servers, tunnels, or other similar services over virtual infrastructure have to justify their addresses based on how many customers they have (as their physical infrastructure isn't necessarily growing). There will also be another round of discussion of this policy at the ARIN Public Policy meeting later this week. -Scott On Tue, Oct 8, 2013 at 10:35 AM, Steven Ryerse wrote: > I keep seeing questions going back and forth on this issue. As I > understand it two things are trying to be accomplished, first ARIN issued > resources are to be primarily used on equipment located within the ARIN > region, and second there needs to be some sort of legal presence with > contact information in the ARIN region that can be kept in the ARIN > database for everyone including law enforcement to access. Can't the > policy simply say there must be a legal presence and the resources must be > used within the ARIN region, and that resources can be de-allocated if > either ceases to be true? > > The elegance of the Internet is that it can expand an organization's reach > - including across RIR boundaries, so who cares if a web server or a > virtual server (or whatever) that is physically located in the ARIN region > is access by tons of folks outside the region. There just needs to be a > legal presence and contact information to go along with that allocation. > Trying to apply some test such as majority or plurality will just cause > unnecessary complexity and the current policies are complex enough without > needlessly adding to it. My 2 cents. > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of John Curran > Sent: Tuesday, October 08, 2013 1:16 PM > To: Frank Bulk > Cc: > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and > IPv6 Address Space to Out-of-region Requestors - Revised > > On Oct 8, 2013, at 9:26 AM, Frank Bulk > wrote: > > > John, > > > > What if Acme Hosting, Inc., located in the Silicon Valley, found a > > niche offering virtualized servers for Asian customers who want to > > have their Internet-based services hosted more closely to the North > American market. > > > > Acme Hosting and their infrastructure are clearly in the U.S., but > > their customers are not in the ARIN region. > > Their physical infrastructure would only qualify for modest address space > in accordance with policy, and this would not change with the addition of > virtualized servers on existing equipment. > > > Does the policy, as currently written, preclude Acme Hosting from > > requesting more address space as their Asian customer base grows? > > Under current policy, they may request additional addresses as their > customers grow. Under the current revised policy text, we would not > consider their customers who are not in region. This side effect (hosting > companies not being able to consider customers who are out of region) may > or may not be desirable, but is understandable given the additional of > customer region as criteria. > > FYI, > /John > > John Curran > President and CEO > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Tue Oct 8 14:30:07 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 08 Oct 2013 19:30:07 +0100 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12013CE81325@ENI-MAIL.eclipse-networks.com> References: <51CB28D3.5090901@abenaki.wabanaki.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> <5B9E90747FA2974D91A54FCFA1B8AD12013CE81325@ENI-MAIL.eclipse-networks.com> Message-ID: <52544F2F.4000901@matthew.at> On 10/8/2013 6:35 PM, Steven Ryerse wrote: > Can't the policy simply say there must be a legal presence and the resources must be used within the ARIN region, and that resources can be de-allocated if either ceases to be true? > > I do like the idea that there will be even more value for legacy holders to not put their space under a RSA. Matthew Kaufman From matthew at matthew.at Tue Oct 8 14:23:26 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 08 Oct 2013 19:23:26 +0100 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> Message-ID: <52544D9E.2030108@matthew.at> John, a few clarifying scenarios below, if you would be so kind as to apply your interpretation both pre- and post-policy to these as well: On 10/8/2013 6:15 PM, John Curran wrote: > On Oct 8, 2013, at 9:26 AM, Frank Bulk > wrote: > >> John, >> >> What if Acme Hosting, Inc., located in the Silicon Valley, found a niche >> offering virtualized servers for Asian customers who want to have their >> Internet-based services hosted more closely to the North American market. >> >> Acme Hosting and their infrastructure are clearly in the U.S., but their >> customers are not in the ARIN region. > Their physical infrastructure would only qualify for modest address space > in accordance with policy, and this would not change with the addition of > virtualized servers on existing equipment. > >> Does the policy, as currently written, preclude Acme Hosting from requesting >> more address space as their Asian customer base grows? > Under current policy, they may request additional addresses as their customers > grow. Under the current revised policy text, we would not consider their > customers who are not in region. This side effect (hosting companies not being > able to consider customers who are out of region) may or may not be desirable, > but is understandable given the additional of customer region as criteria. So if I understand the above response, when Acme Hosting comes and requests more addresses for the VMs because they have a bunch more Asian customers who want a local server presence, you would approve now but deny with the new policy. Correct? And when Acme Hosting, who was doing a brisk business selling VMs to Asian customers, and now has 55% Asian customers in total comes to you to request a bunch of IP addresses for VMs that they are selling to a new set of *US based* customers, you would still approve now but deny (because of the plurality of existing usage) under the new policy? Does the same apply for Acme Websites, who was doing a similarly brisk business with the Asian market, but not for VMs but instead additional IP addresses on physical hosts used for non-SNI SSL hosting? Or are their additional IP addresses that they're assigning to physical hardware interfaces considered by ARIN to be "infrastructure" owned and operated by Acme Websites? (They do respond to ARP requests on the physical Ethernet segment, so it sure feels like they're "really there") How about for Acme Physical Servers, who was also doing a similarly brisk business with the Asian market, but instead of VMs, was out provisioning actual physical hardware for these customers? Are those physical servers which are in use by the Asian customers considered to be customer equipment owned and operated by Asian customers, or infrastructure equipment owned by Acme Physical Servers (who not only has physical possession of the servers, but also the root password and only lets the customers upload website data)? And what do you do when the above Acme Physical Servers gets approved for the space, but realizes they can save a bunch of money selling all their cloud servers on eBay and moving everyone to 1/10th of the remaining machines as VMs? I'm sure I'll have a small number of additional questions after learning the response for each of these, but this should give us enough to think about. Matthew Kaufman From SRyerse at eclipse-networks.com Tue Oct 8 14:40:35 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 8 Oct 2013 18:40:35 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> <5B9E90747FA2974D91A54FCFA1B8AD12013CE81325@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12013CE81735@ENI-MAIL.eclipse-networks.com> The virtual train has left the station. 80% of the servers we are doing now are Virtual and most need Internet IP addresses. Almost all of the Internet IP addresses I?m assigning today are being assigned to virtual servers. Treating them somehow like they are different than say a router in that they need one or more IP addresses makes no sense. An Internet IP address - is an Internet IP address - is an Internet IP address - no matter what it is assigned to. I don?t like adding needless restrictions. -1 Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: Scott Leibrand [mailto:scottleibrand at gmail.com] Sent: Tuesday, October 08, 2013 1:45 PM To: Steven Ryerse Cc: John Curran; Frank Bulk; Subject: Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised Steven, Were you following the discussion at the NANOG PPC? (It's being webcast.) The challenge with what you're describing seems to be that many organizations who provide virtual servers, tunnels, or other similar services over virtual infrastructure have to justify their addresses based on how many customers they have (as their physical infrastructure isn't necessarily growing). There will also be another round of discussion of this policy at the ARIN Public Policy meeting later this week. -Scott On Tue, Oct 8, 2013 at 10:35 AM, Steven Ryerse > wrote: I keep seeing questions going back and forth on this issue. As I understand it two things are trying to be accomplished, first ARIN issued resources are to be primarily used on equipment located within the ARIN region, and second there needs to be some sort of legal presence with contact information in the ARIN region that can be kept in the ARIN database for everyone including law enforcement to access. Can't the policy simply say there must be a legal presence and the resources must be used within the ARIN region, and that resources can be de-allocated if either ceases to be true? The elegance of the Internet is that it can expand an organization's reach - including across RIR boundaries, so who cares if a web server or a virtual server (or whatever) that is physically located in the ARIN region is access by tons of folks outside the region. There just needs to be a legal presence and contact information to go along with that allocation. Trying to apply some test such as majority or plurality will just cause unnecessary complexity and the current policies are complex enough without needlessly adding to it. My 2 cents. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Tuesday, October 08, 2013 1:16 PM To: Frank Bulk Cc: > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised On Oct 8, 2013, at 9:26 AM, Frank Bulk > wrote: > John, > > What if Acme Hosting, Inc., located in the Silicon Valley, found a > niche offering virtualized servers for Asian customers who want to > have their Internet-based services hosted more closely to the North American market. > > Acme Hosting and their infrastructure are clearly in the U.S., but > their customers are not in the ARIN region. Their physical infrastructure would only qualify for modest address space in accordance with policy, and this would not change with the addition of virtualized servers on existing equipment. > Does the policy, as currently written, preclude Acme Hosting from > requesting more address space as their Asian customer base grows? Under current policy, they may request additional addresses as their customers grow. Under the current revised policy text, we would not consider their customers who are not in region. This side effect (hosting companies not being able to consider customers who are out of region) may or may not be desirable, but is understandable given the additional of customer region as criteria. FYI, /John John Curran President and CEO 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From billdarte at gmail.com Tue Oct 8 14:43:20 2013 From: billdarte at gmail.com (Bill Darte) Date: Tue, 8 Oct 2013 13:43:20 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <52544D9E.2030108@matthew.at> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> <52544D9E.2030108@matthew.at> Message-ID: Not to speak for John, but I believe the plurality issue only applies to how the new request would be allocated. bd On Tue, Oct 8, 2013 at 1:23 PM, Matthew Kaufman wrote: > John, a few clarifying scenarios below, if you would be so kind as to > apply your interpretation both pre- and post-policy to these as well: > > On 10/8/2013 6:15 PM, John Curran wrote: > >> On Oct 8, 2013, at 9:26 AM, Frank Bulk >> wrote: >> >> John, >>> >>> What if Acme Hosting, Inc., located in the Silicon Valley, found a niche >>> offering virtualized servers for Asian customers who want to have their >>> Internet-based services hosted more closely to the North American market. >>> >>> Acme Hosting and their infrastructure are clearly in the U.S., but their >>> customers are not in the ARIN region. >>> >> Their physical infrastructure would only qualify for modest address space >> in accordance with policy, and this would not change with the addition of >> virtualized servers on existing equipment. >> >> Does the policy, as currently written, preclude Acme Hosting from >>> requesting >>> more address space as their Asian customer base grows? >>> >> Under current policy, they may request additional addresses as their >> customers >> grow. Under the current revised policy text, we would not consider their >> customers who are not in region. This side effect (hosting companies not >> being >> able to consider customers who are out of region) may or may not be >> desirable, >> but is understandable given the additional of customer region as criteria. >> > > > So if I understand the above response, when Acme Hosting comes and > requests more addresses for the VMs because they have a bunch more Asian > customers who want a local server presence, you would approve now but deny > with the new policy. Correct? > > And when Acme Hosting, who was doing a brisk business selling VMs to Asian > customers, and now has 55% Asian customers in total comes to you to request > a bunch of IP addresses for VMs that they are selling to a new set of *US > based* customers, you would still approve now but deny (because of the > plurality of existing usage) under the new policy? > > Does the same apply for Acme Websites, who was doing a similarly brisk > business with the Asian market, but not for VMs but instead additional IP > addresses on physical hosts used for non-SNI SSL hosting? Or are their > additional IP addresses that they're assigning to physical hardware > interfaces considered by ARIN to be "infrastructure" owned and operated by > Acme Websites? (They do respond to ARP requests on the physical Ethernet > segment, so it sure feels like they're "really there") > > How about for Acme Physical Servers, who was also doing a similarly brisk > business with the Asian market, but instead of VMs, was out provisioning > actual physical hardware for these customers? Are those physical servers > which are in use by the Asian customers considered to be customer equipment > owned and operated by Asian customers, or infrastructure equipment owned by > Acme Physical Servers (who not only has physical possession of the servers, > but also the root password and only lets the customers upload website data)? > > And what do you do when the above Acme Physical Servers gets approved for > the space, but realizes they can save a bunch of money selling all their > cloud servers on eBay and moving everyone to 1/10th of the remaining > machines as VMs? > > I'm sure I'll have a small number of additional questions after learning > the response for each of these, but this should give us enough to think > about. > > Matthew Kaufman > > ______________________________**_________________ > 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: > http://lists.arin.net/mailman/**listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue Oct 8 14:54:06 2013 From: jcurran at arin.net (John Curran) Date: Tue, 8 Oct 2013 18:54:06 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <52544D9E.2030108@matthew.at> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> <52544D9E.2030108@matthew.at> Message-ID: On Oct 8, 2013, at 11:23 AM, Matthew Kaufman wrote: > John, a few clarifying scenarios below, if you would be so kind as to apply your interpretation both pre- and post-policy to these as well: > ... > So if I understand the above response, when Acme Hosting comes and requests more addresses for the VMs because they have a bunch more Asian customers who want a local server presence, you would approve now but deny with the new policy. Correct? Matthew - We verify technical infrastructure and customers - this verifying _existing_ assignments already made. Based on that rate of utilization, the requester will qualify for certain amount of space. Under the new policy, we would only issuance space such that a plurality of new resources were justified by the utilization rate of in-region customers extended forward. > And when Acme Hosting, who was doing a brisk business selling VMs to Asian customers, and now has 55% Asian customers in total comes to you to request a bunch of IP addresses for VMs that they are selling to a new set of *US based* customers, you would still approve now but deny (because of the plurality of existing usage) under the new policy? Correct, the "intent" of the request for additional IP addresses for new in-region customers doesn't matter; we'd still look at the existing usage assigned to customers. > Does the same apply for Acme Websites, who was doing a similarly brisk business with the Asian market, but not for VMs but instead additional IP addresses on physical hosts used for non-SNI SSL hosting? Or are their additional IP addresses that they're assigning to physical hardware interfaces considered by ARIN to be "infrastructure" owned and operated by Acme Websites? (They do respond to ARP requests on the physical Ethernet segment, so it sure feels like they're "really there") We would consider the past utilization of IP addresses assigned to the equipment in region to determine utilization rate going forward. > How about for Acme Physical Servers, who was also doing a similarly brisk business with the Asian market, but instead of VMs, was out provisioning actual physical hardware for these customers? Are those physical servers which are in use by the Asian customers considered to be customer equipment owned and operated by Asian customers, or infrastructure equipment owned by Acme Physical Servers (who not only has physical possession of the servers, but also the root password and only lets the customers upload website data)? We would consider the past utilization of IP addresses assigned to the equipment in region to determine utilization rate going forward. > And what do you do when the above Acme Physical Servers gets approved for the space, but realizes they can save a bunch of money selling all their cloud servers on eBay and moving everyone to 1/10th of the remaining machines as VMs? We generally know how to work with customers who go through equipment changes, including equipment with higher densities of IP address usage. FYI, /John John Curran President and CEO ARIN From lee at dilkie.com Tue Oct 8 14:46:38 2013 From: lee at dilkie.com (Lee Dilkie) Date: Tue, 08 Oct 2013 14:46:38 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12013CE81735@ENI-MAIL.eclipse-networks.com> References: <51CB28D3.5090901@abenaki.wabanaki.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> <5B9E90747FA2974D91A54FCFA1B8AD12013CE81325@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12013CE81735@ENI-MAIL.eclipse-networks .com> Message-ID: <5254530E.50909@dilkie.com> Which leads me to think the era of the regional RIR is over. Time to move back to a single registry. -lee On 10/8/2013 2:40 PM, Steven Ryerse wrote: > > The virtual train has left the station. 80% of the servers we are > doing now are Virtual and most need Internet IP addresses. Almost all > of the Internet IP addresses I'm assigning today are being assigned to > virtual servers. Treating them somehow like they are different than > say a router in that they need one or more IP addresses makes no > sense. An Internet IP address - is an Internet IP address - is an > Internet IP address - no matter what it is assigned to. > > > > I don't like adding needless restrictions. -1 > > > > /Steven Ryerse/ > > /President/ > > /100 Ashford Center North, Suite 110, Atlanta, GA 30338/ > > /770.656.1460 - Cell/ > > /770.399.9099- Office/ > > > > Description: Description: Eclipse Networks Logo_small.png^(SM)Eclipse > Networks, Inc. > > ^ Conquering Complex Networks ^^(SM) ^ > > > > *From:*Scott Leibrand [mailto:scottleibrand at gmail.com] > *Sent:* Tuesday, October 08, 2013 1:45 PM > *To:* Steven Ryerse > *Cc:* John Curran; Frank Bulk; > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of > IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised > > > > Steven, > > > > Were you following the discussion at the NANOG PPC? (It's being webcast.) > > > > The challenge with what you're describing seems to be that many > organizations who provide virtual servers, tunnels, or other similar > services over virtual infrastructure have to justify their addresses > based on how many customers they have (as their physical > infrastructure isn't necessarily growing). > > > > There will also be another round of discussion of this policy at the > ARIN Public Policy meeting later this week. > > > > -Scott > > > > On Tue, Oct 8, 2013 at 10:35 AM, Steven Ryerse > > > wrote: > > I keep seeing questions going back and forth on this issue. As I > understand it two things are trying to be accomplished, first ARIN > issued resources are to be primarily used on equipment located within > the ARIN region, and second there needs to be some sort of legal > presence with contact information in the ARIN region that can be kept > in the ARIN database for everyone including law enforcement to access. > Can't the policy simply say there must be a legal presence and the > resources must be used within the ARIN region, and that resources can > be de-allocated if either ceases to be true? > > The elegance of the Internet is that it can expand an organization's > reach - including across RIR boundaries, so who cares if a web server > or a virtual server (or whatever) that is physically located in the > ARIN region is access by tons of folks outside the region. There > just needs to be a legal presence and contact information to go along > with that allocation. Trying to apply some test such as majority or > plurality will just cause unnecessary complexity and the current > policies are complex enough without needlessly adding to it. My 2 cents. > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > > ^(SM) Eclipse Networks, Inc. > Conquering Complex Networks^(SM) > > > > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net > ] On Behalf Of John Curran > > Sent: Tuesday, October 08, 2013 1:16 PM > To: Frank Bulk > Cc: > > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 > and IPv6 Address Space to Out-of-region Requestors - Revised > > On Oct 8, 2013, at 9:26 AM, Frank Bulk > > wrote: > > > John, > > > > What if Acme Hosting, Inc., located in the Silicon Valley, found a > > niche offering virtualized servers for Asian customers who want to > > have their Internet-based services hosted more closely to the North > American market. > > > > Acme Hosting and their infrastructure are clearly in the U.S., but > > their customers are not in the ARIN region. > > Their physical infrastructure would only qualify for modest address > space in accordance with policy, and this would not change with the > addition of virtualized servers on existing equipment. > > > Does the policy, as currently written, preclude Acme Hosting from > > requesting more address space as their Asian customer base grows? > > Under current policy, they may request additional addresses as their > customers grow. Under the current revised policy text, we would not > consider their customers who are not in region. This side effect > (hosting companies not being able to consider customers who are out of > region) may or may not be desirable, but is understandable given the > additional of customer region as criteria. > > FYI, > /John > > John Curran > President and CEO > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience > any issues. > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience > any issues. > > > > > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1468 bytes Desc: not available URL: From matthew at matthew.at Tue Oct 8 15:57:27 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 08 Oct 2013 20:57:27 +0100 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> <52544D9E.2030108@matthew.at> Message-ID: <525463A7.10109@matthew.at> On 10/8/2013 7:54 PM, John Curran wrote: > On Oct 8, 2013, at 11:23 AM, Matthew Kaufman wrote: > >> John, a few clarifying scenarios below, if you would be so kind as to apply your interpretation both pre- and post-policy to these as well: >> ... >> So if I understand the above response, when Acme Hosting comes and requests more addresses for the VMs because they have a bunch more Asian customers who want a local server presence, you would approve now but deny with the new policy. Correct? > Matthew - > > We verify technical infrastructure and customers - this verifying _existing_ > assignments already made. Based on that rate of utilization, the requester > will qualify for certain amount of space. Under the new policy, we would > only issuance space such that a plurality of new resources were justified > by the utilization rate of in-region customers extended forward. > >> And when Acme Hosting, who was doing a brisk business selling VMs to Asian customers, and now has 55% Asian customers in total comes to you to request a bunch of IP addresses for VMs that they are selling to a new set of *US based* customers, you would still approve now but deny (because of the plurality of existing usage) under the new policy? > Correct, the "intent" of the request for additional IP addresses for new > in-region customers doesn't matter; we'd still look at the existing usage > assigned to customers. > >> Does the same apply for Acme Websites, who was doing a similarly brisk business with the Asian market, but not for VMs but instead additional IP addresses on physical hosts used for non-SNI SSL hosting? Or are their additional IP addresses that they're assigning to physical hardware interfaces considered by ARIN to be "infrastructure" owned and operated by Acme Websites? (They do respond to ARP requests on the physical Ethernet segment, so it sure feels like they're "really there") > We would consider the past utilization of IP addresses assigned to the > equipment in region to determine utilization rate going forward. > >> How about for Acme Physical Servers, who was also doing a similarly brisk business with the Asian market, but instead of VMs, was out provisioning actual physical hardware for these customers? Are those physical servers which are in use by the Asian customers considered to be customer equipment owned and operated by Asian customers, or infrastructure equipment owned by Acme Physical Servers (who not only has physical possession of the servers, but also the root password and only lets the customers upload website data)? > We would consider the past utilization of IP addresses assigned to the > equipment in region to determine utilization rate going forward. > >> And what do you do when the above Acme Physical Servers gets approved for the space, but realizes they can save a bunch of money selling all their cloud servers on eBay and moving everyone to 1/10th of the remaining machines as VMs? > We generally know how to work with customers who go through equipment > changes, including equipment with higher densities of IP address usage. > > FYI, > /John > > John Curran > President and CEO > ARIN > > > > I think you didn't answer my implied question, which is: How do you decide what is "an address assigned to a customer" and what is "an address assigned to the entity itself for its infrastructure" for the case of: 1) physical web servers used by an entity; 2) physical web servers used exclusively by a customer of the entity; 3) physical web servers with >1 address serving web pages where each address is used exclusively be a different customer of the entity; 4) physical servers running >1 virtual server with an assigned address where the virtual servers are used exclusively by the entity; 5) physical servers running >1 virtual server with an assigned address where the virtual servers are used exclusively by customers of the entity. Me, when I assign addresses to things that I own, they're still my addresses on my things, no matter who I let use them or for how long... but it sounds like you have a different interpretation. Matthew Kaufman From matthew at matthew.at Tue Oct 8 16:00:52 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 08 Oct 2013 21:00:52 +0100 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> <52544D9E.2030108@matthew.at> Message-ID: <52546474.5040406@matthew.at> On 10/8/2013 7:54 PM, John Curran wrote: > >> And when Acme Hosting, who was doing a brisk business selling VMs to Asian customers, and now has 55% Asian customers in total comes to you to request a bunch of IP addresses for VMs that they are selling to a new set of *US based* customers, you would still approve now but deny (because of the plurality of existing usage) under the new policy? > Correct, the "intent" of the request for additional IP addresses for new > in-region customers doesn't matter; we'd still look at the existing usage > assigned to customers. > I would claim that this answer is sufficient to know that the proposed policy is wrong on its face, and that if we care about restricting allocations the text we have now needs changing. Obviously the new addresses would be coming from ARIN for use in the ARIN region by customers located in the ARIN region. If that isn't sufficient to get an allocation, I think we broke something. Matthew Kaufman From hannigan at gmail.com Tue Oct 8 18:02:46 2013 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 8 Oct 2013 15:02:46 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <5254530E.50909@dilkie.com> References: <51CB28D3.5090901@abenaki.wabanaki.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> <5B9E90747FA2974D91A54FCFA1B8AD12013CE81325@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12013CE81735@ENI-MAIL.eclipse-networks.com> <5254530E.50909@dilkie.com> Message-ID: Or allowing competition. Best, Marty On Tuesday, October 8, 2013, Lee Dilkie wrote: > Which leads me to think the era of the regional RIR is over. Time to move > back to a single registry. > > -lee > > > On 10/8/2013 2:40 PM, Steven Ryerse wrote: > > The virtual train has left the station. 80% of the servers we are doing > now are Virtual and most need Internet IP addresses. Almost all of the > Internet IP addresses I?m assigning today are being assigned to virtual > servers. Treating them somehow like they are different than say a router > in that they need one or more IP addresses makes no sense. An Internet IP > address - is an Internet IP address - is an Internet IP address - no matter > what it is assigned to. **** > > ** ** > > I don?t like adding needless restrictions. -1**** > > ** ** > > *Steven Ryerse* > > *President* > > *100 Ashford Center North, Suite 110, Atlanta, GA 30338* > > *770.656.1460 - Cell* > > *770.399.9099- Office* > > ** ** > > [image: Description: Description: Eclipse Networks Logo_small.png]? Eclipse > Networks, Inc.**** > > Conquering Complex Networks?**** > > ** ** > > *From:* Scott Leibrand [mailto:scottleibrand at gmail.com] > *Sent:* Tuesday, October 08, 2013 1:45 PM > *To:* Steven Ryerse > *Cc:* John Curran; Frank Bulk; > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 > and IPv6 Address Space to Out-of-region Requestors - Revised**** > > ** ** > > Steven,**** > > ** ** > > Were you following the discussion at the NANOG PPC? (It's being webcast.) > **** > > ** ** > > The challenge with what you're describing seems to be that many > organizations who provide virtual servers, tunnels, or other similar > services over virtual infrastructure have to justify their addresses based > on how many customers they have (as their physical infrastructure isn't > necessarily growing).**** > > ** ** > > There will also be another round of discussion of this policy at the ARIN > Public Policy meeting later this week.**** > > ** ** > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1468 bytes Desc: not available URL: From jcurran at arin.net Tue Oct 8 19:58:04 2013 From: jcurran at arin.net (John Curran) Date: Tue, 8 Oct 2013 23:58:04 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12013CE81735@ENI-MAIL.eclipse-networks.com> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> <5B9E90747FA2974D91A54FCFA1B8AD12013CE81325@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD12013CE81735@ENI-MAIL.eclipse-networks.com> Message-ID: On Oct 8, 2013, at 11:40 AM, Steven Ryerse > wrote: The virtual train has left the station. 80% of the servers we are doing now are Virtual and most need Internet IP addresses. Almost all of the Internet IP addresses I?m assigning today are being assigned to virtual servers. Treating them somehow like they are different than say a router in that they need one or more IP addresses makes no sense. An Internet IP address - is an Internet IP address - is an Internet IP address - no matter what it is assigned to. I don?t like adding needless restrictions. -1 To be clear, the Draft Policy isn't changing how ARIN handles virtual devices; we still verify the customer demand driving those virtual servers if you are using that demand to request additional IP address space. The Draft Policy adds some consideration about region of those customers, but that's simply additional work when verifying customer growth. This is not a statement in favor or opposed to the draft policy, simply clarification regarding the actual effect of its implementation. FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From mysidia at gmail.com Tue Oct 8 20:28:17 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 8 Oct 2013 19:28:17 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <000d01cec443$2666b040$733410c0$@iname.com> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> Message-ID: On Tue, Oct 8, 2013 at 11:26 AM, Frank Bulk wrote: > John, What if Acme Hosting, Inc., located in the Silicon Valley, found a > niche > offering virtualized servers for Asian customers who want to have their > Internet-based services hosted more closely to the North American market. > > Acme Hosting and their infrastructure are clearly in the U.S., but their > customers are not in the ARIN region. [snip] The end user might physically reside in Asia; however, if their virtual server is being hosted physically in the ARIN region, and the hosting company's offices are in the American region, THEN the user is essentially "coming into the ARIN region" to do business. I would make the argument, that these are Asia-based people Doing business in the US, by virtually coming and buying product from a US-based company; they might not be taking a plane trip into the US to setup the account, but they are calling a US phone number, US-based e-mail address, or visiting a US-based website. So while their nationality is Asian, they may in fact be "US customers" If the customer is doing business in the ARIN region; then ARIN should not be examining their nationality too deeply, as long as their full verifiable details are gathered and available for dissemination by ARIN's auditors. -- -JH -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Tue Oct 8 21:42:23 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 9 Oct 2013 01:42:23 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <000d01cec443$2666b040$733410c0$@iname.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12013CE9D9A4@ENI-MAIL.eclipse-networks.com> Absolutely! +1 Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax [Description: Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jimmy Hess Sent: Tuesday, October 08, 2013 8:28 PM To: Frank Bulk Cc: John Curran; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised On Tue, Oct 8, 2013 at 11:26 AM, Frank Bulk > wrote: John, What if Acme Hosting, Inc., located in the Silicon Valley, found a niche offering virtualized servers for Asian customers who want to have their Internet-based services hosted more closely to the North American market. Acme Hosting and their infrastructure are clearly in the U.S., but their customers are not in the ARIN region. [snip] The end user might physically reside in Asia; however, if their virtual server is being hosted physically in the ARIN region, and the hosting company's offices are in the American region, THEN the user is essentially "coming into the ARIN region" to do business. I would make the argument, that these are Asia-based people Doing business in the US, by virtually coming and buying product from a US-based company; they might not be taking a plane trip into the US to setup the account, but they are calling a US phone number, US-based e-mail address, or visiting a US-based website. So while their nationality is Asian, they may in fact be "US customers" If the customer is doing business in the ARIN region; then ARIN should not be examining their nationality too deeply, as long as their full verifiable details are gathered and available for dissemination by ARIN's auditors. -- -JH -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1473 bytes Desc: image001.jpg URL: From mysidia at gmail.com Tue Oct 8 22:48:50 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 8 Oct 2013 21:48:50 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> Message-ID: On Sun, Oct 6, 2013 at 7:53 AM, John Curran wrote: > On Oct 6, 2013, at 5:38 AM, William Herrin > wrote: > > To be clear, ARIN sent the following text (as quoted by Frank) to the > To provide some insight, however, organizations often reference > NRPM (and assert compliance with the policy therein) when their > interpretation is different from that of the staff implementation. > > While staff tries to be true to the language (and the spirit) of > number resource policy as adopted, diligent requesters who have > a credible claim of compliance to NRPM are approved. > WHOA. That's a thorny issue. What you are saying is that staff have an interpretation of policy, and will tell an applicant _no_, they are not eligible to receive the resource X, according to the staff interpretation. BUT, some requestors can choose their own interpretation, without past and future requestors having the benefit of having their request interpreted to comply in that way? This seems like inequal treatment. The problem, is this is application of different rules to different requestors, and unfairly favorable treatment to requestors who can hire a large team of analysts to put together an alternative interpretation favoring the granting of their request. What should instead happen, is ARIN should consult with the community first, before accepting an "alternative credible interpretation," AND inform past applicants who may have had requests denied, that a new interpretation is being accepted, without any change in policy. > Thanks! > /John > -- -JH -------------- next part -------------- An HTML attachment was scrubbed... URL: From frnkblk at iname.com Tue Oct 8 23:03:07 2013 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 8 Oct 2013 22:03:07 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <7C8FD027-9205-49CF-9367-49F04AB4DCE5@delong.com> Message-ID: <011101cec49c$14a8eb80$3dfac280$@iname.com> John: It seems the ARIN staff has taken a "virtualized hosts/devices/infrastructure don't count" approach. I understand ARIN staff's concern about potential abuse by some folk who may spin up a bunch of virtualized servers to get some address space, and then use that address space anywhere in the world and/or in a way that wouldn't have met the NPRM's criteria, but it seems that ARIN's brush is a bit too broad. As others have pointed out at the PPC and in this discussion, virtualization is here to stay, and it doesn't make sense that ARIN staff's practices don't line up with reality if the NPRM doesn't preclude that. The NPRM only talks about hosts, devices, and infrastructure. I don't believe there is anything that requires a physical host or physical infrastructure (i.e. load balancer). Rather than disallow virtualized hosts or infrastructure from contributing to a host count, why not require the requestor to provide some documentation of the validity of these virtualized hosts, perhaps through invoices showing that Customer A had an average of 30 servers and a peak of 45 servers in the last month, Customer B had an average of 10 servers and a peak of 50 servers in the last month, etc, and then some aggregate data that shows many virtualized servers operated on average and at peak. It seems that in general the community trusts ARIN staff to sniff out abuse - and if initially the requestors are required to show the last 3 or 6 or 9 months of invoices or virtualization data, that's a lot better than the current practice of not being willing to count them at all. And just to state my understanding of current practice, the use of virtualization isn't a major factor in current practice if the customers are predominately in the USA, but the concern is if the virtualization hoster has many out-of-region customers. Regards, Frank From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Victor Kuarsingh Sent: Tuesday, October 08, 2013 12:46 PM To: Owen DeLong Cc: John Curran; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised Owen, all, I am in agreement, in general, with text that takes that form if this would cover the cases where the use of the addresses would be used on an interfaces, servers, VMs or other elements which are built upon equipment which is present in the ARIN region. regards, Victor K On Tue, Oct 8, 2013 at 1:06 PM, Owen DeLong > wrote: Perhaps replacing "technical infrastructure" with "addresses assigned to equipment and/or interfaces physically present within the ARIN region". Owen On Oct 7, 2013, at 8:37 AM, John Curran > wrote: > On Oct 6, 2013, at 3:22 PM, William Herrin > wrote: > >> There is a subtlety here that is escaping me. If the addresses are >> assigned to hosted infrastructure within the region then how are they >> not used within the region? > > Bill - > > Apologies in advance for length - the community is entitled to a complete > understanding of how we administer number resources, and that appears to > take more words than I expected at first.. > > Technical infrastructure can be used to justify addresses (for example, > network routers, POP equipment, concentrators, management systems, IT > systems, data center servers, etc.) We're very experienced with this, > and often ask for equipment lists, invoices, etc. to confirm existence > of the asserted equipment. > > When technical infrastructure grows, more IP addresses are needed for > assignment to the technical infrastructure. Technical infrastructure > exists in a region based on the location of the physical devices. > > Customers growth can also justify addresses (e.g. you assign addresses to > an single customer, or customer growth requires that a certain dynamic pool > assigned to customers be expanded) We are also quite experienced with the > verification of customers, including obtaining customer lists, contact info, > etc. > > When the number of customers served grows, more IP addresses are needed to > assign to the new customers, or to assign to the dynamic pools for those > customers. Customers exist in a region, based on their actual location of > each customer. > > For example, if someone needs more addresses because they are adding > new VPN concentrators (i.e. more actual equipment itself), then that is > indeed technical infrastructure need based on where the equipment will > be installed. i.e. if you buy stacks of new VPN concentrators and have > no addresses to connect them to your infrastructure, it's a simple matter > to request (per policy) additional addresses needed. We do this all of > the time with the infrastructure side of DSLAMS, cable head-ends, wifi > nodes, etc. > > If someone needs additional addresses for their _customers_ (including > to expand a dynamically assigned pool), then we verify the customer > growth as noted earlier, including the location of the customers. > > Requesters have to show that they have additional equipment or additional > customers to obtain addition addresses. Both equipment and customers are > associated with real-world addresses, and hence are within some region of > the registry system. > >> What aspect of the draft policy would change that evaluation? ... > > The draft policy 2013-6 reads as follows: > > "In addition to meeting all other applicable policy requirements, > a plurality of new resources requested from ARIN must be justified > by technical infrastructure or customers located within the ARIN > service region, and any located outside the region must be > interconnected to the ARIN service region." > > The requesters who were previously discussed (i.e. "the 52" who have received > allocations since mid-year), often have some existing infrastructure, are not > adding anything more, and do not need more addresses due to their _technical > infrastructure_ growth. > > They do have remarkable customer growth, and hence need additional addresses. > Under the policy change proposed by 2013-6, we would only consider customers > within the ARIN service region for this purpose, and would provide an allocation > which they could justify based on that in-region customer demand. The proposed > policy change makes clear that customers must be in-region to be considered. > (The present policy does not have such a constraint, hence the approval of > recent requests where the vast majority of customers are known to be outside > the ARIN region.) > > We don't consider virtual "technical infrastructure" for assessing the need > for addresses, even though service providers may use such when adding customers. > The additional customers driving such virtual growth are readily verifiable. > The alternative would be to consider virtual equipment (e.g. VM's) as actual > technical infrastructure and that would effectively open the justification of > unlimited resources by any party without any actual equipment or customer growth. > > If the desire was to simply clarify existing policy (without actually changing > the current practice), it could be accomplished by dropping the "in region" > requirement for customers as follows: "must be justified by technical > infrastructure within the ARIN or by customers located anywhere as long as > the addresses are managed and interconnected in the ARIN service region." > (Note that such a change would make rather clear that nearly any heavily-utilized > customer-driven IP address pool interconnected in the ARIN region can qualify > for additional resources, which may or may not be a desirable outcome depending > on one's individual perspective.) > > I hope this helps in clarifying what ARIN-2013-6 would be change to the > existing policy, as it would make clear that customer growth in-region > would be necessary to justify requests, whereas presently we have some > folks requesting resources using nominal equipment within the region and > backed by extensive customer growth external to the region. > > Please do not hesitate to ask if you have any further questions - it is > indeed very important that folks understand how we implement the policy > in order to fully consider any proposed policy changes, so thank you for > your diligence on this topic. > > /John > > John Curran > President and CEO > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue Oct 8 23:07:49 2013 From: jcurran at arin.net (John Curran) Date: Wed, 9 Oct 2013 03:07:49 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> Message-ID: On Oct 8, 2013, at 7:48 PM, Jimmy Hess wrote: > While staff tries to be true to the language (and the spirit) of > number resource policy as adopted, diligent requesters who have > a credible claim of compliance to NRPM are approved. > > WHOA. That's a thorny issue. What you are saying is that staff have an interpretation of policy, > and will tell an applicant _no_, they are not eligible to receive the resource X, according to the staff interpretation. The existing number resource policy manual supports these requests, and that's why they are approved. Once we realized this type of request were valid (and yet potentially unexpected), we did report it to the community in the Policy Implementation and Experience report. Once 2013-6 is disposed off either way, we will initiate a review of the procedures, including the messaging sent to requestors. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Tue Oct 8 23:23:27 2013 From: jcurran at arin.net (John Curran) Date: Wed, 9 Oct 2013 03:23:27 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <011101cec49c$14a8eb80$3dfac280$@iname.com> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <7C8FD027-9205-49CF-9367-49F04AB4DCE5@delong.com> <011101cec49c$14a8eb80$3dfac280$@iname.com> Message-ID: <407D8369-08DE-4049-B75F-A8D967F230DD@arin.net> On Oct 8, 2013, at 8:03 PM, Frank Bulk > wrote: It seems the ARIN staff has taken a ?virtualized hosts/devices/infrastructure don?t count? approach. I understand ARIN staff?s concern about potential abuse by some folk who may spin up a bunch of virtualized servers to get some address space, and then use that address space anywhere in the world and/or in a way that wouldn?t have met the NPRM?s criteria, but it seems that ARIN?s brush is a bit too broad. Frank - ARIN has always verified customers in determining address need but is happy to change if directed by the community. That would be a change to existing policy and should be discussed with the ARIN AC to develop an appropriate policy proposal. Review NRPM 4.2.3 - Reassigning Address Space to Customers for the current policy, as that is the basis for issuing additional IP address space to service providers. (You can also find more information on utilization under the corresponding online procedures ) Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue Oct 8 23:38:19 2013 From: jcurran at arin.net (John Curran) Date: Wed, 9 Oct 2013 03:38:19 +0000 Subject: [arin-ppml] more - Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised - In-Reply-To: <011101cec49c$14a8eb80$3dfac280$@iname.com> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <7C8FD027-9205-49CF-9367-49F04AB4DCE5@delong.com> <"CADiurz1=6R=7VcFH1gz3y1ODwx1D9UJ19CmarnE=86u LfyBAZg"@mail.gmail.com> <011101cec49c$14a8eb80$3dfac280$@iname.com> Message-ID: <37E0CA30-2EA4-4B05-9107-B2E83343E35B@arin.net> On Oct 8, 2013, at 8:03 PM, Frank Bulk > wrote: As others have pointed out at the PPC and in this discussion, virtualization is here to stay, and it doesn?t make sense that ARIN staff?s practices don?t line up with reality if the NPRM doesn?t preclude that. The NPRM only talks about hosts, devices, and infrastructure. We have many service providers using virtualization with no problem at all; it is completely compatible with ARIN's policies. To be clear, the policy manual discusses IP address _for customers_, and that is what is described under NRPM 4.2 (allocations to ISPs). New requests are verified based on documenting the assignment of the address space of the last block out to individual customers. Those customers can be on dedicated servers, shared servers, virtual servers, or anything else. I don?t believe there is anything that requires a physical host or physical infrastructure (i.e. load balancer). Rather than disallow virtualized hosts or infrastructure from contributing to a host count, why not require the requestor to provide some documentation of the validity of these virtualized hosts, perhaps through invoices showing that Customer A had an average of 30 servers and a peak of 45 servers in the last month, Customer B had an average of 10 servers and a peak of 50 servers in the last month, etc, and then some aggregate data that shows many virtualized servers operated on average and at peak. It seems that in general the community trusts ARIN staff to sniff out abuse ? and if initially the requestors are required to show the last 3 or 6 or 9 months of invoices or virtualization data, that?s a lot better than the current practice of not being willing to count them at all. Additional allocations are not based on equipment, but on utilization of the last IP address block via assignments to customers. If ISP A gets to 80% because of great virtual hosting sales, they can come get new addresses, regardless of the actual technology used. It is true that if an ISP bought some equipment and used the addresses to turn it up, we'll consider those IP addresses assigned as well, but primary driver is documented customer assignments. FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Wed Oct 9 00:42:44 2013 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 8 Oct 2013 21:42:44 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <5242FA37.7000304@arin.net> Message-ID: Fully agreed. This is seemingly running out of control. To be clear, I fully support LEA intent. I suspect they are getting bad advice on policy creation. Let's start over and help. Best, -M< On Wednesday, September 25, 2013, William Herrin wrote: > On Wed, Sep 25, 2013 at 10:59 AM, ARIN > > wrote: > > must > > provide proof that they (1) are an active business entity legally > > operating within the ARIN service region > > Howdy, > > Speaking for myself, this is unacceptable. I am adamantly, totally, > 100% against this, in concept and execution. > > This kind of restriction on international commerce is usually reserved > for national security issues. Foreign interests own ARIN region > infrastructure and do business with ARIN region customers all the > time, without registering themselves with the government. Just as > ARIN-region businesses do in Europe, Asia and elsewhere. Until there's > a need for employees in a country, it's not generally necessary and > often inappropriate to incorporate there. > > I think ARIN should continue to follow the same ordinary business > practice everyone else does when it comes to the legal status of its > registrants: as long as there's a contactable legal existence > somewhere (and it's incumbent on the registrant to prove it) they > should pass muster as an organization capable of requesting resources. > > > >, and (2) are operating a > > network located within the ARIN service region. In addition to meeting > > all other applicable policy requirements, a plurality of new resources > > "Plurality" is a non-starter for me. You really want to do this, pick a > percent. > > The reasons have all been stated before, both in the previous > discussion, the staff comments and the legal assessment. In context, > plurality is a sloppy, hard to pin down concept that makes management > and analysis needlessly hard. > > > > As reported at the last meeting in Barbados, ARIN staff is having > > difficulty verifying organizations out-of-region. In many of the cases, > > particularly in VPS (Virtual Private Service), the only information > > received on these organizations by ARIN is a customer name and IP > > address. This information cannot be properly verified by ARIN. Accuracy > > of registration data is critical to not only law enforcement, but the > > greater ARIN community as it relates to abuse contact and complaints. In > > fact, most issues facing law enforcement are also shared by legitimate > > companies attempting, for instance, to identify an organization that has > > hijacked their IP address space. > > Do I correctly read the expectation that the verification process ARIN > would apply to its direct registrants is expected to be adopted down > stream by service providers as they assign addresses to their > customers? What a godawful mess that would make! > > If not, then how exactly does the draft policy address the problem noted > above? > > > > I don't say this often, but for all of the reasons above I > respectfully encourage the AC to abandon this proposal. The issues > raised by our law enforcement colleagues are legitimate, but this > approach to solving them is not credible. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com > bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Wed Oct 9 03:33:13 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 09 Oct 2013 08:33:13 +0100 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> Message-ID: <525506B9.6070102@matthew.at> On 10/7/2013 4:37 PM, John Curran wrote: > We don't consider virtual "technical infrastructure" for assessing the > need for addresses, even though service providers may use such when > adding customers. The additional customers driving such virtual growth > are readily verifiable. The alternative would be to consider virtual > equipment (e.g. VM's) as actual technical infrastructure and that > would effectively open the justification of unlimited resources by any > party without any actual equipment or customer growth. I'm pretty sure that we must "consider virtual equipment (e.g. VM's) as actual technical infrastructure". The actual businesses that are being built on the Internet appear to have outpaced policy here. If I host a large computing cloud or storage cloud, I really need to be able to get additional address space as that cloud grows. There may be no addresses that are "assigned to a specific customer" or even a "pool of addresses that are used by specific customers" in the traditional ISP sense. In fact, I might consider myself an end-user of IP space, not an ISP, and be attempting to get address space as an end-user. And the growth of the exposed IP surface of that cloud may or may not be a linear function of the physical resources I throw at it. In fact, as the physical resources get more powerful, I would expect not. When Google comes back for more address space under the proposed policy, will they be denied because this week more Google searches are being initiated (by what Google considers their "customers") from outside of the ARIN region? Matthew Kaufman From matthew at matthew.at Wed Oct 9 03:42:27 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 09 Oct 2013 08:42:27 +0100 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <5243A640.7050602@abenaki.wabanaki.net> <2CFB3C56-1B70-4266-A5A5-F90F101FCB2B@virtualized.org> <7DF1E996-D747-4103-B626-90C4014441A8@delong.com> Message-ID: <525508E3.4010801@matthew.at> On 9/28/2013 3:34 AM, John Curran wrote: > > > Bill - > > As noted earlier, the proposal that was submitted referenced three reasons > = > > 1. The rapid depletion of IPv4 space resulting from the present situation, > 2. The challenging environment for law enforcement investigations, including > the opportunity unscrupulous organizations to manipulate the system and > acquire large blocks of ARIN IP address space for nefarious purposes, > 3. The direct contravention of the Regional Internet Registry system resulting > from ARIN assigning resources outside the region and implications for the > current model. > > My reading of the language of the proposal is that it would *not* apply to the needs justification for 8.3 transfers. Thus #2 above, for the IPv4 case, is about to become irrelevant, once the easiest way to "acquire large blocks of ARIN IP address space for nefarious purposes" is to simply buy them on the transfer market. Matthew Kaufman From jcurran at arin.net Wed Oct 9 04:17:34 2013 From: jcurran at arin.net (John Curran) Date: Wed, 9 Oct 2013 08:17:34 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <525506B9.6070102@matthew.at> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <525506B9.6070102@matthew.at> Message-ID: On Oct 9, 2013, at 12:33 AM, Matthew Kaufman wrote: > I'm pretty sure that we must "consider virtual equipment (e.g. VM's) as actual technical infrastructure". The actual businesses that are being built on the Internet appear to have outpaced policy here. > > If I host a large computing cloud or storage cloud, I really need to be able to get additional address space as that cloud grows. There may be no addresses that are "assigned to a specific customer" or even a "pool of addresses that are used by specific customers" in the traditional ISP sense. In fact, I might consider myself an end-user of IP space, not an ISP, and be attempting to get address space as an end-user. And the growth of the exposed IP surface of that cloud may or may not be a linear function of the physical resources I throw at it. In fact, as the physical resources get more powerful, I would expect not. > ... Congrats, you're an end-user. You get an address block, and when its used, you ask for more and we verify the usage of the prior block. The fact that many, many IPs are assigned to a handful of devices doesn't matter, as long as they are utilized. This is per the NRPM 4.3.6 end-user policies, and works quite well today with ARIN performing verification across if wide variety of technologies, including addresses deployed into virtual infrastructure. Under the end-user policies, this is quite possible, but we're quite likely to ask for additional information in order correlate your recent growth which other metrics. Thanks! /John John Curran President and CEO ARIN From matthew at matthew.at Wed Oct 9 05:03:53 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 09 Oct 2013 10:03:53 +0100 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <525506B9.6070102@matthew.at> Message-ID: <52551BF9.7070406@matthew.at> On 10/9/2013 9:17 AM, John Curran wrote: > On Oct 9, 2013, at 12:33 AM, Matthew Kaufman wrote: > >> I'm pretty sure that we must "consider virtual equipment (e.g. VM's) as actual technical infrastructure". The actual businesses that are being built on the Internet appear to have outpaced policy here. >> >> If I host a large computing cloud or storage cloud, I really need to be able to get additional address space as that cloud grows. There may be no addresses that are "assigned to a specific customer" or even a "pool of addresses that are used by specific customers" in the traditional ISP sense. In fact, I might consider myself an end-user of IP space, not an ISP, and be attempting to get address space as an end-user. And the growth of the exposed IP surface of that cloud may or may not be a linear function of the physical resources I throw at it. In fact, as the physical resources get more powerful, I would expect not. >> ... > Congrats, you're an end-user. You get an address block, and > when its used, you ask for more and we verify the usage of the > prior block. The fact that many, many IPs are assigned to a > handful of devices doesn't matter, as long as they are utilized. > > This is per the NRPM 4.3.6 end-user policies, and works quite > well today with ARIN performing verification across if wide > variety of technologies, including addresses deployed into > virtual infrastructure. Under the end-user policies, this is > quite possible, but we're quite likely to ask for additional > information in order correlate your recent growth which other > metrics. > > And under the proposed policy your usage verification would require "a plurality of new resources requested from ARIN must be justified by technical infrastructure or customers located within the ARIN service region"... and so if you don't count my virtual servers as "technical infrastructure" (see your previous reply: "We don't consider virtual 'technical infrastructure' for assessing the need for addresses") and the "customers" of my cloud service happen to be mostly outside of the ARIN service region, what then? Matthew Kaufman From jcurran at arin.net Wed Oct 9 10:30:25 2013 From: jcurran at arin.net (John Curran) Date: Wed, 9 Oct 2013 14:30:25 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <52551BF9.7070406@matthew.at> References: <51CB28D3.5090901@abenaki.wabanaki.net> <524376E5.7030906@abenaki.wabanaki.net> <7566EDA7-3397-4AA2-A387-96F0B018A9D8@corp.arin.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <525506B9.6070102@matthew.at> <52551BF9.7070406@matthew.at> Message-ID: On Oct 9, 2013, at 2:03 AM, Matthew Kaufman wrote: > On Oct 9, 2013, at 12:33 AM, Matthew Kaufman wrote: >> If I host a large computing cloud or storage cloud, I really need to be able to get additional address space as that cloud grows. There may be no addresses that are "assigned to a specific customer" or even a "pool of addresses that are used by specific customers" in the traditional ISP sense. In fact, I might consider myself an end-user of IP space, not an ISP, and be attempting to get address space as an end-user. And the growth of the exposed IP surface of that cloud may or may not be a linear function of the physical resources I throw at it. In fact, as the physical resources get more powerful, I would expect not. > ... > And under the proposed policy your usage verification would require "a plurality of new resources requested from ARIN must be justified by technical infrastructure or customers located within the ARIN service region"... and so if you don't count my virtual servers as "technical infrastructure" (see your previous reply: "We don't consider virtual 'technical infrastructure' for assessing the need for addresses") and the "customers" of my cloud service happen to be mostly outside of the ARIN service region, what then? Under the present policy, your _end-user_ request would be approved if you could credibly shown that you have used 80% of all previously assigned address blocks. We have no need to consider the regional nature of the customer or equipments usage that led to this, but do need credible evidence of the utilization. Under the proposed policy, your _end-user_ request would be still approved if you could credibly shown that you have used 80% of all previously assigned address blocks (this does not change.) Note that we now need to credibly determine the regional nature of the customer or equipment growth behind that utilization. Per your example, you've assigned a lot of IP addresses to a small amount of in-region equipment, and as long as that can be confirmed, your request would be approved, _but predominantly because you are requesting an additional block as an end-user under NRPM 4.3.6, and not an ISP requesting an additional block under NRPM 4.2.4. ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning that space to their customers, and that means the proposed policy would significantly impact ISPs who assigned IP addresses to customers out of region. This is the correct result, as the draft policy adds the consideration of the service region of the customers or equipment as a criteria, but otherwise does not change how ARIN presently considers customer growth or equipment growth in verification of requests under ISP or end-user policies. It is the nature of ARIN's policies for ISPs which require consideration of the customers, and under the proposed policy, customer location. Note you failed to include my complete quote in your reference above, it was: >>> "We don't consider virtual "technical infrastructure" for assessing the need for addresses, _even though service providers may use such when adding customers._" Per NRPM 4.2, requests for address space _from an ISP_ is justified based on customer growth. Your example above is, per your own words, and end-user request and hence my quote on service providers is not applicable. Today, customer and equipment growth outside the region qualifies today for determining utilization and would not qualify under the proposed policy. The proposed policy does not change the handling of virtual infrastructure, and ISP requests will still need to be backed by customer growth in any case. Thanks! /John John Curran President and CEO ARIN From matthew at matthew.at Wed Oct 9 10:35:12 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 09 Oct 2013 15:35:12 +0100 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: References: <51CB28D3.5090901@abenaki.wabanaki.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <525506B9.6070102@matthew.at> <52551BF9.7070406@matthew.at> Message-ID: <525569A0.9040305@matthew.at> On 10/9/2013 3:30 PM, John Curran wrote: > On Oct 9, 2013, at 2:03 AM, Matthew Kaufman wrote: >> On Oct 9, 2013, at 12:33 AM, Matthew Kaufman wrote: >>> If I host a large computing cloud or storage cloud, I really need to be able to get additional address space as that cloud grows. There may be no addresses that are "assigned to a specific customer" or even a "pool of addresses that are used by specific customers" in the traditional ISP sense. In fact, I might consider myself an end-user of IP space, not an ISP, and be attempting to get address space as an end-user. And the growth of the exposed IP surface of that cloud may or may not be a linear function of the physical resources I throw at it. In fact, as the physical resources get more powerful, I would expect not. >> ... >> And under the proposed policy your usage verification would require "a plurality of new resources requested from ARIN must be justified by technical infrastructure or customers located within the ARIN service region"... and so if you don't count my virtual servers as "technical infrastructure" (see your previous reply: "We don't consider virtual 'technical infrastructure' for assessing the need for addresses") and the "customers" of my cloud service happen to be mostly outside of the ARIN service region, what then? > Under the present policy, your _end-user_ request would be approved if you could > credibly shown that you have used 80% of all previously assigned address blocks. > We have no need to consider the regional nature of the customer or equipments > usage that led to this, but do need credible evidence of the utilization. > > Under the proposed policy, your _end-user_ request would be still approved if you > could credibly shown that you have used 80% of all previously assigned address > blocks (this does not change.) Note that we now need to credibly determine the > regional nature of the customer or equipment growth behind that utilization. Interesting. I do wonder if that is what the original authors of the policy intended, because this seems to be the opposite of what they would want to happen in such a case... end-user assignment or not, the "users" they want to have authority over would be out-of-region. (And sure, they could come to the hosting company and tell it to shut a service down, but that's true when an ISP routes packets to a customer as well, and so why are they asking for what they're asking for?) Matthew Kaufman From owen at delong.com Wed Oct 9 15:47:01 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Oct 2013 12:47:01 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <525569A0.9040305@matthew.at> References: <51CB28D3.5090901@abenaki.wabanaki.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <525506B9.6070102@matthew.at> <52551BF9.7070406@matthew.at> <525569A0.9040305@matthew.at> Message-ID: <1B32550E-7A90-4D89-AB91-0FD7DC4F6B73@delong.com> Geoff Huston made some eloquent comments on this policy at the NANOG PPC yesterday. I asked him to repeat those comments on the list. I received the following comment from Geoff Huston off-list. I repost it here with his permission? > I should note that as a member of APNIC staff I am > neither for nor against this proposal, and my comment here is intended to > be more of a comment that reflects on the role of address plans and the > utility and value of the network. Nevertheless I'm sure that my own > opinions will become evident here, but I would not like the ARIN AC folk to > pay such opinions any attention in the context of their further > consideration of the sense of the ARIN address policy community. > > For some years I have advocated the benefits of managing addresses within > the framework of the Regional Internet Registry administrative model in > venues that were accustomed to immediately thinking that such matters were > most appropritely matters for countries to manage individually and > separately as sovereign entities. > > My response to this was to point out that right from the start, if there > was one thing that was fundamental about the Internet that was different to > many other technologies at the time was that it was borderless. In the 80's > you applied to the Internic and completed your application for IP addresses > and they responded with a confirmation that you had received an address > block and it was uniquely assigned to you. And I could use these addresses > anywhere I chose. That did not mean that doing business on the net was > instantly enabled, or anything even close to that, but it was one less > impediment in the path. The Regional Internet Registries did not spring up > from a desire to build ring fences around geographies, but oddly enough > quite the opposite. It was to make this process of obtaining addresses even > easier and more convenient. You could speak to someone in your own time > zone, who hopefully spoke your langiuage, but the end outcome, the address > assignment, was precisely the same: a block of addresses that could be used > anywhere on the Internet, and reachable by everyone else. > > This breaking down of such impediments has happened in many ways and in > many places, but the cumulative result has been the enabling of activities > that have proved to be highly effective and engaging across the entire > globe, and at the same time creating considerable economic value all over > the world. Internet addresses that were not geo-politically scoped were not > the only reaon for this, and perhaps this is not often listed in everyone's > top 10 reasons why the Internet has managed to surpass everyone's > expectations about its prospects, but it was is important factor > nevertheless. If we had managed to fracture the address plant at any time > in the past by putting arbitrary forms of ring fences around addresses, > then I'd guess that we would not have got the Internet to where it is today. > > So it seems to me that there are good reasons why you want to keep looking > for ways to break down further impediments and barriers to use the > Internet, and ways to make the network a tool for access to a seamless > global environment. And, equally, there are probably many reasons to pause > and reflect on the longer term implications of reverting to regional, or > even national address plans. We many want to reflect on the network's > routing architecture and the relationship of address frameworks and the > costs and scaleability of global routing, or reflect on the value of ready > access to a global population of clients for your services, and the ability > to leverage the Internet to provide the most efficiently sourced services > to customers without the overt impositions of localized barriers and > impositions. > > It's not that an open address model naturally enables all these beneficial > outcomes, because it does not, but perhaps there is reason to think that > the reverse, namely the imposition of a localised addressing model, does > make a net contribution to the costs and overheads in using the Internet > rather than to it's benefits. From drc at virtualized.org Wed Oct 9 17:56:02 2013 From: drc at virtualized.org (David Conrad) Date: Wed, 9 Oct 2013 14:56:02 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised In-Reply-To: <1B32550E-7A90-4D89-AB91-0FD7DC4F6B73@delong.com> References: <51CB28D3.5090901@abenaki.wabanaki.net> <843CEB5F-B65B-4E6A-B601-7AA620D6281A@arin.net> <037A7436-7F3E-4C8F-96E0-176FF3E794FA@arin.net> <42C9B415-75DB-4AB7-955F-BD84AB9C64EC@arin.net> <7EFC324C-F324-4FD0-A168-4C40DBC70F96@arin.net> <77FF27E0-7B89-4574-B845-938319CE29C9@arin.net> <9C8AE4BD-A903-434D-8B5F-32E24AFFBE0B@arin.net> <525506B9.6070102@matthew.at> <52551BF9.7070406@matthew.at> <525569A0.9040305@matthew.at> <1 B32550E- 7A90-4D89-AB91-0FD7DC4F6B73@delong.com> Message-ID: <5D6C5D0D-DEB3-458A-AD3D-E69CC655A054@virtualized.org> Hi, Commenting on Geoff's note: >> The Regional Internet Registries did not spring up >> from a desire to build ring fences around geographies, but oddly enough >> quite the opposite. While I won't bother exploring RIR history, the end result (perhaps not surprisingly) has been exactly that, as evidenced by existing AfriNIC policy and the LACNIC proposal (and effective practice). Pragmatically, this means that in the case of the remaining free pools of IPv4 (ARIN, AfriNIC, and LACNIC), only the ARIN pool is without an explicit policy requirement of in-region use. The practical implication of this is that the ARIN pool will serve not just the ARIN region applicants but (as we have seen) applicants from the AP region and the European region. This has and will have the obvious impact of draining the ARIN free pool faster than what would otherwise be the case. One can make the argument that this is not necessarily bad, e.g., it will accelerate the need to migrate to IPv6 (which has to happen regardless) or ARIN serving as the "registry for the global addressless" is in the best interests of the ARIN community or the Internet as a whole. One can also argue that policy to combat this is too hard to define/implement, etc. On the other hand, one could say, the RIRs were established to serve regional addressing requirements and as such, addresses should be allocated for in-region use. In either case, I believe the ARIN community should make a decision on which of these views they believe is appropriate for the ARIN region and policy should be made explicit in order to provide extremely clear guidance to staff -- it seems there is currently too much ambiguity and misunderstanding about this topic. >> It was to make this process of obtaining addresses even >> easier and more convenient. You could speak to someone in your own time >> zone, who hopefully spoke your langiuage, And yet, the situation in question is precisely the opposite. >> So it seems to me that there are good reasons why you want to keep looking >> for ways to break down further impediments and barriers to use the >> Internet, and ways to make the network a tool for access to a seamless >> global environment. And, equally, there are probably many reasons to pause >> and reflect on the longer term implications of reverting to regional, or >> even national address plans. At a global policy perspective, there is indeed a question as to the appropriate direction forward -- the arguments made by Geoff could easily be taken as suggesting the RIR system should revert back to a singular global registry with a single, unified addressing plan and allocation mechanism. There are, of course, numerous folks who would argue that national bodies should take over that function. And there are undoubtedly those who believe the status quo is just fine. However, we still have a few more months of IPv4 and the reality of limited pools, uneven distribution, and lack of parity in allocation policy amongst the RIRs with free pools. From my point of view, this is what 2013-6 is looking to address. Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From info at arin.net Wed Oct 16 15:29:30 2013 From: info at arin.net (ARIN) Date: Wed, 16 Oct 2013 15:29:30 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - October 2013 Message-ID: <525EE91A.3090901@arin.net> In accordance with the ARIN Policy Development Process the ARIN Advisory Council (AC) held a meeting on 11 October 2013 and made decisions about several draft policies. The AC moved the following draft policy to last call (it will be posted separately to last call): Recommended Draft Policy ARIN-2013-4: RIR Principles The following remains on the AC's docket: Draft Policy ARIN-2013-7: Merge IPv4 ISP and End-User Requirements The AC abandoned the following: Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors The AC provided the following statement about 2013-6: ##### "The ARIN Advisory Council voted to abandon ARIN-2013-6 "Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors". Based on the community's feedback at the NANOG 59 Public Policy Consultation and ARIN 32 Public Policy Meeting last week, the AC feels that the text proposed is unlikely to ever reach consensus. The AC does believe, however, that the problems 2013-6 tried to address are real, and will look to the community to suggest one or more alternative solutions in the future. Abandonment may permit more clearly addressing each of two important questions that were combined in the proposal. First, there may be benefit from a clearer policy regarding what requirements for an in-region presence are necessary before an allocation is made. The feedback at the meetings indicated that the community did not favor a standard based on a "majority" or "plurality" of in-region customers or infrastructure, and that such a standard might interfere with the legitimate operations of many global businesses or global service providers based within the ARIN region. Second, greater consideration is needed as to whether the perceived need for better verification of the identity of the applicant is an issue that can or should be addressed outside of the number resource policy process, since it may be more properly an aspect of ARIN's business practices. Follow on work may reveal that splitting such issues into multiple policies will permit greater clarity and consensus on these issues from the community." ##### The AC abandoned ARIN-2013-6. Anyone dissatisfied with this decision may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Oct 16 15:34:50 2013 From: info at arin.net (ARIN) Date: Wed, 16 Oct 2013 15:34:50 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-4: RIR Principles Message-ID: <525EEA5A.9030809@arin.net> The ARIN Advisory Council (AC) met on 11 October 2013 and decided to send the following draft policy to last call: Recommended Draft Policy ARIN-2013-4: RIR Principles The draft has been revised in accordance with changes that were presented at the ARIN Public Policy Consultation at NANOG 59 and at ARIN 32. The Section Title was changed to "Principles and Goals of the American Registry for Internet Numbers (ARIN)," and an example was moved from the third paragraph of Stewardship to the comments section. Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 30 October 2013. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Recommended Draft Policy ARIN-2013-4 RIR Principles Date: 16 October 2013 Policy Statement: Section 0: Principles and Goals of the American Registry for Internet Numbers (ARIN) 0.1. Registration The principle of registration guarantees the uniqueness of Internet number resources. Provision of this public registry documenting Internet number resource allocation, reallocation, assignment, and reassignment is necessary: a) to ensure uniqueness, b) to provide a contact in case of operational/security problems, c) to provide the transparency required to ensure that Internet number resources are efficiently utilized, and d) to assist in IP allocation studies. 0.2. Conservation The principle of conservation guarantees sustainability of the Internet through efficient utilization of unique number resources. Due to the requirement for uniqueness, Internet number resources of each type are drawn from a common number space. Conservation of these common number spaces requires that Internet number resources be efficiently distributed to those organizations who have a technical need for them in support of operational networks. 0.3. Routability The principle of routability guarantees that Internet number resources are managed in such a manner that they may be routed on the Internet in a scalable manner. While routing scalability is necessary to ensure proper operation of Internet routing, allocation or assignment of Internet number resources by ARIN in no way guarantees that those addresses will be routed by any particular network operator. 0.4. Stewardship The principle of stewardship guarantees the application of these principles when managing Internet number resources. The fundamental purpose of Internet number stewardship is to distribute unique number resources to entities building and operating networks thereby facilitating the growth and sustainability of the Internet for the benefit of all. It should be noted that the above goals may sometimes be in conflict with each other and with the interests of individual end-users or network operators. Care must be taken to ensure balance with these conflicting goals given the resource availability, relative size of the resource, and number resource specific technical dynamics, for each type of number resource. Comments: a. Timetable for implementation: immediately b. I believe that it would be beneficial for IANA to adopt these principles as well, and encourage the community to consider a global policy proposal. Text removed from third paragraph of Stewardship above: For example, Conservation often requires greater consideration in IPv4 address distribution due to the limited size of the address space, Routability has a higher weight for the massive IPv6 address space, and AS numbers place the highest value on Registration because they come from a moderately sized pool and are not subject to aggregation. AC's assessment of conformance with the Principles of Internet Number Resource Policy: ARIN-2013-4 "RIR Principles" was moved to recommended draft policy status for adoption discussion at ARIN 32. The majority of the AC believes that documenting the existing principles under which ARIN operates uniquely enables fair and impartial number resource administration and that these principles are technically sound, based on their history and heritage. The AC also notes that the current text, after being revised to incorporate staff and community feedback, now has community support. Problem Statement: The original text in RFC 2050 both "describes the registry system for the distribution of globally unique Internet address space and registry operations" and provides "rules and guidelines [principles] governing the distribution of this address space." The currently proposed update (RFC2050bis) "provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers" and "provides information about the processes for further evolution of the Internet Numbers Registry System." This means that the guiding principles of stewardship are not currently being carried forward into the new document. The goals of Conservation (efficient utilization based on need), Routability (hierarchical aggregation), and Registration (uniqueness) are as important, if not more so, now that the transition to IPv6 is upon us. This can be rectified by documenting these principles in RIR policy. ########## ARIN Staff and Legal Assessment DRAFT NUMBER AND NAME: 2013-4 Principles and Goals of the Internet Registry System DATE: 17 September 2013 1. Summary (Staff Understanding) This policy would add text to the NRPM which codifies the guiding principles of the registry system as registration, conservation, routability, and stewardship. 2. Comments A. ARIN Staff Comments ?? This proposal text is clear. ?? Staff notes that the proposal does not appear to change any existing processes or procedures. ?? It appears that the author's intent is to add these statements as guiding principles into the NRPM. ?? Their inclusion into the policy manual will make it more clear to the community the principles under which ARIN has operated. ?? For reference, the term ??Registration?? already exists in NRPM as follows: ?? 4.2.3.7. Registration - Refers to ISPs providing reassignment information, so it's not applicable. ?? 6.3.3. Registration - This section has some overlap, could be reduced, but also refers to privacy. ?? 6.5.5. Registration - Refers to reassignment information, so it's not applicable. ?? The term ??Conservation?? exists already in 6.3.5 but is different and specific to IPv6. ?? The addition of the term ??Routability?? would make a portion of NRPM 4.1.1 redundant. ?? The term "Stewardship" would add that word anew to the NRPM. ?? The statement about conflicting goals should not refer to any specific type of number resource if it is a principle. o Suggestion - Allow the specific conflicts to exist in the particular section. Remove everything from "For example" on. ?? Note also that NRPM 6.3.8 already talks about conflict of goals, noting "aggregation" as the most important goal for IPv6. ?? Staff suggests different placement/numbering, in particular, moving the introduction text up into the Abstract section before the TOC, thus freeing up Section 1 for ??RIR Principles??. ?? It is worth noting that the ARIN Policy Development Process contains the following: "4. Principles of Internet Number Resource Policy?? Internet number resource policy must satisfy three important principles, specifically: 1) enabling fair and impartial number resource administration, 2) technically sound (providing for uniqueness and usability of number resources), and 3) supported by the community." Furthermore that the RFC 7020 contains references to ??1) Allocation Pool Management, 2) Hierarchical Allocation, and 3) Registration Accuracy??. It is suggested that the policy text be reviewed to avoid duplication with these existing principles. B. ARIN General Counsel - Legal Assessment The text of the policy does not create a material legal issue for ARIN. Any effort like this to accurately incorporate in writing the concepts that animate ARIN's activity is a positive development. 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: A. Updated guidelines B. Staff training From narten at us.ibm.com Fri Oct 18 09:14:59 2013 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 18 Oct 2013 09:14:59 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201310181314.r9IDExtc017727@rotala.raleigh.ibm.com> Total of 2 messages in the last 7 days. script run at: Fri Oct 18 09:14:59 EDT 2013 Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 19977 | info at arin.net --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 19977 | Total From mueller at syr.edu Fri Oct 18 14:44:56 2013 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 18 Oct 2013 18:44:56 +0000 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-4: RIR Principles In-Reply-To: <525EEA5A.9030809@arin.net> References: <525EEA5A.9030809@arin.net> Message-ID: <855077AC3D7A7147A7570370CA01ECD251BB96@SUEX10-mbx-10.ad.syr.edu> opposed, for reasons set out repeatedly in PPMs and AC meetings. --MM ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] on behalf of ARIN [info at arin.net] Sent: Wednesday, October 16, 2013 3:34 PM To: arin-ppml at arin.net Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-4: RIR Principles The ARIN Advisory Council (AC) met on 11 October 2013 and decided to send the following draft policy to last call: Recommended Draft Policy ARIN-2013-4: RIR Principles The draft has been revised in accordance with changes that were presented at the ARIN Public Policy Consultation at NANOG 59 and at ARIN 32. The Section Title was changed to "Principles and Goals of the American Registry for Internet Numbers (ARIN)," and an example was moved from the third paragraph of Stewardship to the comments section. Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 30 October 2013. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Recommended Draft Policy ARIN-2013-4 RIR Principles Date: 16 October 2013 Policy Statement: Section 0: Principles and Goals of the American Registry for Internet Numbers (ARIN) 0.1. Registration The principle of registration guarantees the uniqueness of Internet number resources. Provision of this public registry documenting Internet number resource allocation, reallocation, assignment, and reassignment is necessary: a) to ensure uniqueness, b) to provide a contact in case of operational/security problems, c) to provide the transparency required to ensure that Internet number resources are efficiently utilized, and d) to assist in IP allocation studies. 0.2. Conservation The principle of conservation guarantees sustainability of the Internet through efficient utilization of unique number resources. Due to the requirement for uniqueness, Internet number resources of each type are drawn from a common number space. Conservation of these common number spaces requires that Internet number resources be efficiently distributed to those organizations who have a technical need for them in support of operational networks. 0.3. Routability The principle of routability guarantees that Internet number resources are managed in such a manner that they may be routed on the Internet in a scalable manner. While routing scalability is necessary to ensure proper operation of Internet routing, allocation or assignment of Internet number resources by ARIN in no way guarantees that those addresses will be routed by any particular network operator. 0.4. Stewardship The principle of stewardship guarantees the application of these principles when managing Internet number resources. The fundamental purpose of Internet number stewardship is to distribute unique number resources to entities building and operating networks thereby facilitating the growth and sustainability of the Internet for the benefit of all. It should be noted that the above goals may sometimes be in conflict with each other and with the interests of individual end-users or network operators. Care must be taken to ensure balance with these conflicting goals given the resource availability, relative size of the resource, and number resource specific technical dynamics, for each type of number resource. Comments: a. Timetable for implementation: immediately b. I believe that it would be beneficial for IANA to adopt these principles as well, and encourage the community to consider a global policy proposal. Text removed from third paragraph of Stewardship above: For example, Conservation often requires greater consideration in IPv4 address distribution due to the limited size of the address space, Routability has a higher weight for the massive IPv6 address space, and AS numbers place the highest value on Registration because they come from a moderately sized pool and are not subject to aggregation. AC's assessment of conformance with the Principles of Internet Number Resource Policy: ARIN-2013-4 "RIR Principles" was moved to recommended draft policy status for adoption discussion at ARIN 32. The majority of the AC believes that documenting the existing principles under which ARIN operates uniquely enables fair and impartial number resource administration and that these principles are technically sound, based on their history and heritage. The AC also notes that the current text, after being revised to incorporate staff and community feedback, now has community support. Problem Statement: The original text in RFC 2050 both "describes the registry system for the distribution of globally unique Internet address space and registry operations" and provides "rules and guidelines [principles] governing the distribution of this address space." The currently proposed update (RFC2050bis) "provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers" and "provides information about the processes for further evolution of the Internet Numbers Registry System." This means that the guiding principles of stewardship are not currently being carried forward into the new document. The goals of Conservation (efficient utilization based on need), Routability (hierarchical aggregation), and Registration (uniqueness) are as important, if not more so, now that the transition to IPv6 is upon us. This can be rectified by documenting these principles in RIR policy. ########## ARIN Staff and Legal Assessment DRAFT NUMBER AND NAME: 2013-4 Principles and Goals of the Internet Registry System DATE: 17 September 2013 1. Summary (Staff Understanding) This policy would add text to the NRPM which codifies the guiding principles of the registry system as registration, conservation, routability, and stewardship. 2. Comments A. ARIN Staff Comments ?? This proposal text is clear. ?? Staff notes that the proposal does not appear to change any existing processes or procedures. ?? It appears that the author's intent is to add these statements as guiding principles into the NRPM. ?? Their inclusion into the policy manual will make it more clear to the community the principles under which ARIN has operated. ?? For reference, the term ??Registration?? already exists in NRPM as follows: ?? 4.2.3.7. Registration - Refers to ISPs providing reassignment information, so it's not applicable. ?? 6.3.3. Registration - This section has some overlap, could be reduced, but also refers to privacy. ?? 6.5.5. Registration - Refers to reassignment information, so it's not applicable. ?? The term ??Conservation?? exists already in 6.3.5 but is different and specific to IPv6. ?? The addition of the term ??Routability?? would make a portion of NRPM 4.1.1 redundant. ?? The term "Stewardship" would add that word anew to the NRPM. ?? The statement about conflicting goals should not refer to any specific type of number resource if it is a principle. o Suggestion - Allow the specific conflicts to exist in the particular section. Remove everything from "For example" on. ?? Note also that NRPM 6.3.8 already talks about conflict of goals, noting "aggregation" as the most important goal for IPv6. ?? Staff suggests different placement/numbering, in particular, moving the introduction text up into the Abstract section before the TOC, thus freeing up Section 1 for ??RIR Principles??. ?? It is worth noting that the ARIN Policy Development Process contains the following: "4. Principles of Internet Number Resource Policy?? Internet number resource policy must satisfy three important principles, specifically: 1) enabling fair and impartial number resource administration, 2) technically sound (providing for uniqueness and usability of number resources), and 3) supported by the community." Furthermore that the RFC 7020 contains references to ??1) Allocation Pool Management, 2) Hierarchical Allocation, and 3) Registration Accuracy??. It is suggested that the policy text be reviewed to avoid duplication with these existing principles. B. ARIN General Counsel - Legal Assessment The text of the policy does not create a material legal issue for ARIN. Any effort like this to accurately incorporate in writing the concepts that animate ARIN's activity is a positive development. 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: A. Updated guidelines B. Staff training _______________________________________________ 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From bill at herrin.us Fri Oct 18 14:52:38 2013 From: bill at herrin.us (William Herrin) Date: Fri, 18 Oct 2013 14:52:38 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-4: RIR Principles In-Reply-To: <525EEA5A.9030809@arin.net> References: <525EEA5A.9030809@arin.net> Message-ID: On Wed, Oct 16, 2013 at 3:34 PM, ARIN wrote: > Recommended Draft Policy ARIN-2013-4: RIR Principles Reluctantly opposed as previously discussed. Would be cautiously in favor if the dangerously vague point #4 was stripped before adoption. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From SRyerse at eclipse-networks.com Fri Oct 18 15:24:24 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 18 Oct 2013 19:24:24 +0000 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-4:RIR Principles In-Reply-To: <855077AC3D7A7147A7570370CA01ECD251BB96@SUEX10-mbx-10.ad.syr.edu> References: <525EEA5A.9030809@arin.net> <855077AC3D7A7147A7570370CA01ECD251BB96@SUEX10-mbx-10.ad.syr.edu> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201425902C8@ENI-MAIL.eclipse-networks.com> -1 as well for the same reasons. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099- Office ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller Sent: Friday, October 18, 2013 2:45 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-4:RIR Principles opposed, for reasons set out repeatedly in PPMs and AC meetings. --MM ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] on behalf of ARIN [info at arin.net] Sent: Wednesday, October 16, 2013 3:34 PM To: arin-ppml at arin.net Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-4: RIR Principles The ARIN Advisory Council (AC) met on 11 October 2013 and decided to send the following draft policy to last call: Recommended Draft Policy ARIN-2013-4: RIR Principles The draft has been revised in accordance with changes that were presented at the ARIN Public Policy Consultation at NANOG 59 and at ARIN 32. The Section Title was changed to "Principles and Goals of the American Registry for Internet Numbers (ARIN)," and an example was moved from the third paragraph of Stewardship to the comments section. Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 30 October 2013. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Recommended Draft Policy ARIN-2013-4 RIR Principles Date: 16 October 2013 Policy Statement: Section 0: Principles and Goals of the American Registry for Internet Numbers (ARIN) 0.1. Registration The principle of registration guarantees the uniqueness of Internet number resources. Provision of this public registry documenting Internet number resource allocation, reallocation, assignment, and reassignment is necessary: a) to ensure uniqueness, b) to provide a contact in case of operational/security problems, c) to provide the transparency required to ensure that Internet number resources are efficiently utilized, and d) to assist in IP allocation studies. 0.2. Conservation The principle of conservation guarantees sustainability of the Internet through efficient utilization of unique number resources. Due to the requirement for uniqueness, Internet number resources of each type are drawn from a common number space. Conservation of these common number spaces requires that Internet number resources be efficiently distributed to those organizations who have a technical need for them in support of operational networks. 0.3. Routability The principle of routability guarantees that Internet number resources are managed in such a manner that they may be routed on the Internet in a scalable manner. While routing scalability is necessary to ensure proper operation of Internet routing, allocation or assignment of Internet number resources by ARIN in no way guarantees that those addresses will be routed by any particular network operator. 0.4. Stewardship The principle of stewardship guarantees the application of these principles when managing Internet number resources. The fundamental purpose of Internet number stewardship is to distribute unique number resources to entities building and operating networks thereby facilitating the growth and sustainability of the Internet for the benefit of all. It should be noted that the above goals may sometimes be in conflict with each other and with the interests of individual end-users or network operators. Care must be taken to ensure balance with these conflicting goals given the resource availability, relative size of the resource, and number resource specific technical dynamics, for each type of number resource. Comments: a. Timetable for implementation: immediately b. I believe that it would be beneficial for IANA to adopt these principles as well, and encourage the community to consider a global policy proposal. Text removed from third paragraph of Stewardship above: For example, Conservation often requires greater consideration in IPv4 address distribution due to the limited size of the address space, Routability has a higher weight for the massive IPv6 address space, and AS numbers place the highest value on Registration because they come from a moderately sized pool and are not subject to aggregation. AC's assessment of conformance with the Principles of Internet Number Resource Policy: ARIN-2013-4 "RIR Principles" was moved to recommended draft policy status for adoption discussion at ARIN 32. The majority of the AC believes that documenting the existing principles under which ARIN operates uniquely enables fair and impartial number resource administration and that these principles are technically sound, based on their history and heritage. The AC also notes that the current text, after being revised to incorporate staff and community feedback, now has community support. Problem Statement: The original text in RFC 2050 both "describes the registry system for the distribution of globally unique Internet address space and registry operations" and provides "rules and guidelines [principles] governing the distribution of this address space." The currently proposed update (RFC2050bis) "provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers" and "provides information about the processes for further evolution of the Internet Numbers Registry System." This means that the guiding principles of stewardship are not currently being carried forward into the new document. The goals of Conservation (efficient utilization based on need), Routability (hierarchical aggregation), and Registration (uniqueness) are as important, if not more so, now that the transition to IPv6 is upon us. This can be rectified by documenting these principles in RIR policy. ########## ARIN Staff and Legal Assessment DRAFT NUMBER AND NAME: 2013-4 Principles and Goals of the Internet Registry System DATE: 17 September 2013 1. Summary (Staff Understanding) This policy would add text to the NRPM which codifies the guiding principles of the registry system as registration, conservation, routability, and stewardship. 2. Comments A. ARIN Staff Comments ?? This proposal text is clear. ?? Staff notes that the proposal does not appear to change any existing processes or procedures. ?? It appears that the author's intent is to add these statements as guiding principles into the NRPM. ?? Their inclusion into the policy manual will make it more clear to the community the principles under which ARIN has operated. ?? For reference, the term ??Registration?? already exists in NRPM as follows: ?? 4.2.3.7. Registration - Refers to ISPs providing reassignment information, so it's not applicable. ?? 6.3.3. Registration - This section has some overlap, could be reduced, but also refers to privacy. ?? 6.5.5. Registration - Refers to reassignment information, so it's not applicable. ?? The term ??Conservation?? exists already in 6.3.5 but is different and specific to IPv6. ?? The addition of the term ??Routability?? would make a portion of NRPM 4.1.1 redundant. ?? The term "Stewardship" would add that word anew to the NRPM. ?? The statement about conflicting goals should not refer to any specific type of number resource if it is a principle. o Suggestion - Allow the specific conflicts to exist in the particular section. Remove everything from "For example" on. ?? Note also that NRPM 6.3.8 already talks about conflict of goals, noting "aggregation" as the most important goal for IPv6. ?? Staff suggests different placement/numbering, in particular, moving the introduction text up into the Abstract section before the TOC, thus freeing up Section 1 for ??RIR Principles??. ?? It is worth noting that the ARIN Policy Development Process contains the following: "4. Principles of Internet Number Resource Policy?? Internet number resource policy must satisfy three important principles, specifically: 1) enabling fair and impartial number resource administration, 2) technically sound (providing for uniqueness and usability of number resources), and 3) supported by the community." Furthermore that the RFC 7020 contains references to ??1) Allocation Pool Management, 2) Hierarchical Allocation, and 3) Registration Accuracy??. It is suggested that the policy text be reviewed to avoid duplication with these existing principles. B. ARIN General Counsel - Legal Assessment The text of the policy does not create a material legal issue for ARIN. Any effort like this to accurately incorporate in writing the concepts that animate ARIN's activity is a positive development. 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: A. Updated guidelines B. Staff training _______________________________________________ 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From hannigan at gmail.com Fri Oct 18 15:50:17 2013 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 18 Oct 2013 15:50:17 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-4: RIR Principles Message-ID: Opposed. On Friday, October 18, 2013, Steven Ryerse wrote: > -1 as well for the same reasons. > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099- Office > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Milton L Mueller > Sent: Friday, October 18, 2013 2:45 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy > ARIN-2013-4:RIR Principles > > opposed, for reasons set out repeatedly in PPMs and AC meetings. > --MM > ________________________________________ > From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] on behalf > of ARIN [info at arin.net] > Sent: Wednesday, October 16, 2013 3:34 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-4: RIR > Principles > > The ARIN Advisory Council (AC) met on 11 October 2013 and decided to send > the following draft policy to last call: > > Recommended Draft Policy ARIN-2013-4: RIR Principles > > The draft has been revised in accordance with changes that were presented > at the ARIN Public Policy Consultation at NANOG 59 and at ARIN 32. The > Section Title was changed to "Principles and Goals of the American Registry > for Internet Numbers (ARIN)," and an example was moved from the third > paragraph of Stewardship to the comments section. > > Feedback is encouraged during the last call period. All comments should be > provided to the Public Policy Mailing List. This last call will expire on > 30 October 2013. After last call the AC will conduct their last call review. > > The draft policy text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Recommended Draft Policy ARIN-2013-4 > RIR Principles > > Date: 16 October 2013 > > Policy Statement: > > Section 0: Principles and Goals of the American Registry for Internet > Numbers (ARIN) > > 0.1. Registration > > The principle of registration guarantees the uniqueness of Internet number > resources. > > Provision of this public registry documenting Internet number resource > allocation, reallocation, assignment, and reassignment is necessary: > a) to ensure uniqueness, > b) to provide a contact in case of operational/security problems, > c) to provide the transparency required to ensure that Internet number > resources are efficiently utilized, and > d) to assist in IP allocation studies. > > 0.2. Conservation > > The principle of conservation guarantees sustainability of the Internet > through efficient utilization of unique number resources. > > Due to the requirement for uniqueness, Internet number resources of each > type are drawn from a common number space. Conservation of these common > number spaces requires that Internet number resources be efficiently > distributed to those organizations who have a technical need for them in > support of operational networks. > > 0.3. Routability > > The principle of routability guarantees that Internet number resources are > managed in such a manner that they may be routed on the Internet in a > scalable manner. > > While routing scalability is necessary to ensure proper operation of > Internet routing, allocation or assignment of Internet number resources by > ARIN in no way guarantees that those addresses will be routed by any > particular network operator. > > 0.4. Stewardship > > The principle of stewardship guarantees the application of these > principles when managing Internet number resources. > > The fundamental purpose of Internet number stewardship is to distribute > unique number resources to entities building and operating networks thereby > facilitating the growth and sustainability of the Internet for the benefit > of all. > > It should be noted that the above goals may sometimes be in conflict with > each other and with the interests of individual end-users or network > operators. Care must be taken to ensure balance with these conflicting > goals given the resource availability, relative size of the resource, and > number resource sp -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogwallah at gmail.com Fri Oct 18 20:06:47 2013 From: dogwallah at gmail.com (McTim) Date: Fri, 18 Oct 2013 20:06:47 -0400 Subject: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-4: RIR Principles In-Reply-To: <525EEA5A.9030809@arin.net> References: <525EEA5A.9030809@arin.net> Message-ID: On Wed, Oct 16, 2013 at 3:34 PM, ARIN wrote: > The ARIN Advisory Council (AC) met on 11 October 2013 and decided to > send the following draft policy to last call: > > Recommended Draft Policy ARIN-2013-4: RIR Principles I am happy to support 2013-4. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From info at arin.net Mon Oct 21 14:55:20 2013 From: info at arin.net (ARIN) Date: Mon, 21 Oct 2013 14:55:20 -0400 Subject: [arin-ppml] ARIN 32 Meeting Report Now Available Message-ID: <52657898.7090707@arin.net> The report of the ARIN 32 Public Policy and Members Meeting in Phoenix, including presentations, summary notes, webcast archives and transcripts, is now available on the ARIN website at: https://www.arin.net/participate/meetings/reports/ARIN_32/ We would like to thank everyone in the community who participated in person and remotely. Please plan to join us 13-16 April 2014 for ARIN 33 in Chicago, Illinois to continue to participate in this integral part of the Internet number resource Policy Development Process. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From narten at us.ibm.com Fri Oct 25 08:05:13 2013 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 25 Oct 2013 08:05:13 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201310251205.r9PC5D6A012282@rotala.raleigh.ibm.com> Total of 7 messages in the last 7 days. script run at: Fri Oct 25 08:05:13 EDT 2013 Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.29% | 1 | 22.80% | 15119 | hannigan at gmail.com 14.29% | 1 | 22.76% | 15091 | sryerse at eclipse-networks.com 14.29% | 1 | 21.43% | 14213 | mueller at syr.edu 14.29% | 1 | 9.14% | 6060 | narten at us.ibm.com 14.29% | 1 | 8.36% | 5542 | bill at herrin.us 14.29% | 1 | 8.34% | 5533 | dogwallah at gmail.com 14.29% | 1 | 7.17% | 4752 | info at arin.net --------+------+--------+----------+------------------------ 100.00% | 7 |100.00% | 66310 | Total From gdendy at equinix.com Wed Oct 30 17:12:06 2013 From: gdendy at equinix.com (Greg Dendy) Date: Wed, 30 Oct 2013 14:12:06 -0700 Subject: [arin-ppml] NANOG 60 - Atlanta - Call For Presentations is open! Message-ID: <18336F94-2430-4F60-B060-51C81719DF5A@equinix.com> NANOG Community, I hope everyone enjoyed NANOG 59 in Phoenix, NANOG?s largest attended meeting. Fresh off a great meeting, and our NANOG annual elections, we are already starting to get ready for NANOG 60 in Atlanta. If you have a topic you'd like to speak about, the program committee would love to consider it. Please read http://www.nanog.org/meetings/nanog60/callforpresentations for more information. We will continue with the Monday-Wednesday format, with Tracks on Monday afternoon and Tutorials to be scheduled on Tuesday morning. The program will begin on Monday morning at 10:00AM followed by our popular Newcomers Lunch. The exact schedule layout can be found at http://www.nanog.org/meetings/nanog60/preagenda, please take this into account as you plan travel. If you wish to submit a presentation, please keep these important dates in mind: * Presentation Abstracts and Draft Slides Due: December 9, 2013 * Final Slides Due: January 6, 2014 * Topic List Posted: December 20, 2013 * Agenda Published: January 13, 2014 Please submit your materials to http://pc.nanog.org. Looking forward to seeing everyone in Atlanta! Thanks, Greg Dendy Chair, NANOG Program Committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Thu Oct 31 15:19:25 2013 From: info at arin.net (ARIN) Date: Thu, 31 Oct 2013 15:19:25 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - October 2013 In-Reply-To: <525EE91A.3090901@arin.net> References: <525EE91A.3090901@arin.net> Message-ID: <5272AD3D.5020701@arin.net> >> The AC abandoned ARIN-2013-6. Anyone dissatisfied with this decision may >> initiate a petition. The deadline to begin a petition will be five >> business days after the AC's draft meeting minutes are published. The minutes of the AC's 11 October 2013 meeting have been published and are available at: https://www.arin.net/about_us/ac/ac2013_1011.html The deadline to begin a petition is 7 November 2013. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 10/16/13 3:29 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process the ARIN Advisory > Council (AC) held a meeting on 11 October 2013 and made decisions about > several draft policies. > > The AC moved the following draft policy to last call (it will be > posted separately to last call): > > Recommended Draft Policy ARIN-2013-4: RIR Principles > > The following remains on the AC's docket: > > Draft Policy ARIN-2013-7: Merge IPv4 ISP and End-User Requirements > > The AC abandoned the following: > > Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to > Out-of-region Requestors > > The AC provided the following statement about 2013-6: > ##### > "The ARIN Advisory Council voted to abandon ARIN-2013-6 "Allocation of > IPv4 and IPv6 Address Space to Out-of-region Requestors". Based on the > community's feedback at the NANOG 59 Public Policy Consultation and ARIN > 32 Public Policy Meeting last week, the AC feels that the text proposed > is unlikely to ever reach consensus. The AC does believe, however, that > the problems 2013-6 tried to address are real, and will look to the > community to suggest one or more alternative solutions in the future. > > Abandonment may permit more clearly addressing each of two important > questions that were combined in the proposal. First, there may be > benefit from a clearer policy regarding what requirements for an > in-region presence are necessary before an allocation is made. The > feedback at the meetings indicated that the community did not favor a > standard based on a "majority" or "plurality" of in-region customers or > infrastructure, and that such a standard might interfere with the > legitimate operations of many global businesses or global service > providers based within the ARIN region. Second, greater consideration > is needed as to whether the perceived need for better verification of > the identity of the applicant is an issue that can or should be > addressed outside of the number resource policy process, since it may be > more properly an aspect of ARIN's business practices. > > Follow on work may reveal that splitting such issues into multiple > policies will permit greater clarity and consensus on these issues from > the community." > ##### > > The AC abandoned ARIN-2013-6. Anyone dissatisfied with this decision may > initiate a petition. The deadline to begin a petition will be five > business days after the AC's draft meeting minutes are published. For > more information on starting and participating in petitions, see PDP > Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > Draft Policy and Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) >