From hannigan at gmail.com Mon Apr 2 14:09:48 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 2 Apr 2012 14:09:48 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6D1499.9010909@matthew.at> <4F6D4788.3000907@matthew.at> Message-ID: On Sat, Mar 31, 2012 at 2:48 PM, Tom Vest wrote: > > On Mar 26, 2012, at 3:51 PM, Martin Hannigan wrote: > > > On Sat, Mar 24, 2012 at 12:03 AM, Matthew Kaufman > wrote: > >> On 3/23/2012 8:18 PM, Owen DeLong wrote: > >>> > >>> On Mar 23, 2012, at 5:26 PM, Matthew Kaufman wrote: > >>> > >>>> On 3/16/2012 2:23 PM, Tom Vest wrote: > >>>>> > >>>>> The knowledge that route (a) was originated by AS (x) is only > meaningful > >>>>> insofar as one has some set of high-confidence beliefs/expectations > about AS > >>>>> (x). However, if AS (x) can change hands at will, henceforth no such > >>>>> confidence will be possible for the overwhelming majority if not all > ASes. > >>>> > >>>> I would point out that this fact is *already* true, as ASNs are > >>>> transferred through merger and acquisition all the time, and have > been for > >>>> over a decade. > >>>> > >>>> I don't see anyone proposing a policy where an entity is required to > >>>> return (and have permanently marked as unavailable) their ASN when > ownership > >>>> changes... I see, for instance, that AS 1 and AS 701 are still out > there, > >>>> despite the above happening several times, and yet nothing terrible > has > >>>> happened as a result. > >>>> > >>> I don't see acquiring the reputation of a network when acquiring the > >>> entire network as being all that likely to be harmful. > >> > >> > >> What makes you think that ASNs acquired through M&A transfer always come > >> with "the entire network"? > >> > >> > >> > >>> At the time of acquisition, the network is still behaving according to > >>> its reputation and what is done will cause necessary modifications to > that > >>> reputation as time goes by. > >> > >> > >> Yes. Perhaps immediately, as the new owners are of course entirely > different > >> people with likely different motivations. The network might immediately > have > >> vastly different traffic patterns. Etc. > >> > >> > >>> > >>> On the other hand, I can see tremendous potential for mischief when > >>> acquiring an AS Number on the open market without having to take on the > >>> operation of said network as part of the package. > >> > >> > >> No different than the current situation. You simply make more money for > the > >> lawyers when you require that it use the M&A transfer process. > >> > >> > >>> I think these are very different scenarios. > >>> > >>> Again, I think we're seeing enough problems created by allowing > transfers > >>> with IPv4 addresses > >> > >> > >> Really? What problems are those? From where I sit, I've seen none. > >> > >> And are those any different than the problems that already existed with > >> transfers of IPv4 addresses via M&A transfer? > > > > > > I've said similar things in this thread and I'll simply add +1. > > > > What we seem to be talking about here, at least from the counter > > argument perspective, is a desire to regulate business process instead > > of providing a technically sound and useful mechanism to enable ASN > > transfers. As someone involved in peering with literally hundreds of > > networks, I'm not convinced that there is a risk that I need to be so > > concerned about that I would want to disallow ASN transfers, > > especially without a single real life incident that is compelling > > enough to warrant a change in thought. > > > > Adopting this policy will allow ARIN to "get out of the way" and > > legitimize what's already transpiring on a regular basis. This is a > > good thing. > > > > > > Best, > > > > -M< > > > [ clip ] > > If adopted, an ASN transfer proposal like the one under discussion would > inevitably contribute to the accelerated erosion of that third-party > authentication mechanism that (almost) everyone has to rely on. > I'm still not sure exactly what third party authentication scheme you are talking about. > > As a thought experiment, I urge you to consider how you might feel if you > *were not* actively "involved in peering with literally hundreds of > networks," and *could not* rely on [NETWORK] unique private capabilities as > a complete substitute for the identification/authentication mechanisms that > are embodied in current AS distribution policies. > > No change. Transferring ASN's is at least innocuous as transferring v4 prefixes with regards to stewardship. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From tvest at eyeconomics.com Mon Apr 2 15:17:52 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Mon, 2 Apr 2012 15:17:52 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6D1499.9010909@matthew.at> <4F6D4788.3000907@matthew.at> Message-ID: <8B58F6D3-5280-418D-8CB8-E9FA7049980F@eyeconomics.com> On Apr 2, 2012, at 2:09 PM, Martin Hannigan wrote: > On Sat, Mar 31, 2012 at 2:48 PM, Tom Vest wrote: > > On Mar 26, 2012, at 3:51 PM, Martin Hannigan wrote: > > > On Sat, Mar 24, 2012 at 12:03 AM, Matthew Kaufman wrote: > >> On 3/23/2012 8:18 PM, Owen DeLong wrote: > >>> > >>> On Mar 23, 2012, at 5:26 PM, Matthew Kaufman wrote: > >>> > >>>> On 3/16/2012 2:23 PM, Tom Vest wrote: > >>>>> > >>>>> The knowledge that route (a) was originated by AS (x) is only meaningful > >>>>> insofar as one has some set of high-confidence beliefs/expectations about AS > >>>>> (x). However, if AS (x) can change hands at will, henceforth no such > >>>>> confidence will be possible for the overwhelming majority if not all ASes. > >>>> > >>>> I would point out that this fact is *already* true, as ASNs are > >>>> transferred through merger and acquisition all the time, and have been for > >>>> over a decade. > >>>> > >>>> I don't see anyone proposing a policy where an entity is required to > >>>> return (and have permanently marked as unavailable) their ASN when ownership > >>>> changes... I see, for instance, that AS 1 and AS 701 are still out there, > >>>> despite the above happening several times, and yet nothing terrible has > >>>> happened as a result. > >>>> > >>> I don't see acquiring the reputation of a network when acquiring the > >>> entire network as being all that likely to be harmful. > >> > >> > >> What makes you think that ASNs acquired through M&A transfer always come > >> with "the entire network"? > >> > >> > >> > >>> At the time of acquisition, the network is still behaving according to > >>> its reputation and what is done will cause necessary modifications to that > >>> reputation as time goes by. > >> > >> > >> Yes. Perhaps immediately, as the new owners are of course entirely different > >> people with likely different motivations. The network might immediately have > >> vastly different traffic patterns. Etc. > >> > >> > >>> > >>> On the other hand, I can see tremendous potential for mischief when > >>> acquiring an AS Number on the open market without having to take on the > >>> operation of said network as part of the package. > >> > >> > >> No different than the current situation. You simply make more money for the > >> lawyers when you require that it use the M&A transfer process. > >> > >> > >>> I think these are very different scenarios. > >>> > >>> Again, I think we're seeing enough problems created by allowing transfers > >>> with IPv4 addresses > >> > >> > >> Really? What problems are those? From where I sit, I've seen none. > >> > >> And are those any different than the problems that already existed with > >> transfers of IPv4 addresses via M&A transfer? > > > > > > I've said similar things in this thread and I'll simply add +1. > > > > What we seem to be talking about here, at least from the counter > > argument perspective, is a desire to regulate business process instead > > of providing a technically sound and useful mechanism to enable ASN > > transfers. As someone involved in peering with literally hundreds of > > networks, I'm not convinced that there is a risk that I need to be so > > concerned about that I would want to disallow ASN transfers, > > especially without a single real life incident that is compelling > > enough to warrant a change in thought. > > > > Adopting this policy will allow ARIN to "get out of the way" and > > legitimize what's already transpiring on a regular basis. This is a > > good thing. > > > > > > Best, > > > > -M< > > [ clip ] > > > If adopted, an ASN transfer proposal like the one under discussion would inevitably contribute to the accelerated erosion of that third-party authentication mechanism that (almost) everyone has to rely on. > > I'm still not sure exactly what third party authentication scheme you are talking about. The existing shared/standardized third-party authentication scheme for ASNs that I'm talking about is the RIRs. Whenever someone submits a request for a new AS to one the RIRs, they're probably not going to very happy with the result unless they also provide credible, complete, and verifiable contact information about themselves along with that request -- with "credible," "complete," and "verifiable" all having some canonical meaning that is applied consistently to all requesters (and which is ultimately made accessible consistently, as necessary for operational purposes, via whois). The RIR honors such requests IFF those criteria, and in some cases other requirements (e.g., needs benchmarking, multihoming, et al.) are satisfied. Thus, under the current process, no ASN that has not been "authenticated" is issued -- or to put it another way, every ASN that is issued under the current system has been authenticated, or "authentically associated" with some consistent, standardized reckoning of who/what the requesting entity is. > As a thought experiment, I urge you to consider how you might feel if you *were not* actively "involved in peering with literally hundreds of networks," and *could not* rely on [NETWORK] unique private capabilities as a complete substitute for the identification/authentication mechanisms that are embodied in current AS distribution policies. > > > No change. Transferring ASN's is at least innocuous as transferring v4 prefixes with regards to stewardship. Do you really believe that? Can you route a prefix without (somebody's) ASN? Can you exercise direct management authority over interconnection and inter-domain traffic exchange relations that (at least potentially) can have transitive/global consequences without your own AS? To the (limited) extent that I agree with you, the strongest implication would be that *both* IPv4 prefix transfers *and* ASN transfers represent grave medium/long-term threats to Internet security and stability -- threats that I remain convinced that we won't have to live very long to regret. However, the truth is that opening the floodgates to "naked" ASN transfers would be exponentially more dangerous than the already-approved IPv4 transfer mechanisms -- and adding AS transfers *on top of* an as-yet untested and unproven IPv4 marketplace would be profoundly foolhardy. Speaking for myself only, TV > Best, > > -M< From owen at delong.com Mon Apr 2 15:42:13 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Apr 2012 12:42:13 -0700 Subject: [arin-ppml] DRAFT POLICY 2012-3: ASN TRANSFERS In-Reply-To: <4F762804.6070100@umn.edu> References: <1120330112006.56017D-100000@Ives.egh.com> <0AE39222-F337-45DE-B3E3-91A7B9F23E05@gmail.com> <4F75DF15.7060509@burnttofu.net> <21CD3214-FEA6-44A5-AFE5-47CBF579F962@gmail.com> <4F762804.6070100@umn.edu> Message-ID: On Mar 30, 2012, at 2:39 PM, David Farmer wrote: > > > On 3/30/12 11:54 CDT, Scott Leibrand wrote: >> On Mar 30, 2012, at 9:28 AM, Michael Sinatra wrote: >>> You seem to be saying that it's not actual reputation that is being >>> traded, but some sort of misperception that ASNs in a certain number >>> range bring credibility. So rather than trade on actual reputation >>> (which I would question in itself), you are advocating creating a market >>> where a fake perception of reputation is what's traded. That doesn't >>> sound to me like a market that will efficiently allocate resources, >>> although it may efficiently allocate misperception. >>> >>> IPv4 number transfers make sense. IPv6 number transfers do not. I am >>> on the fence about ASN transfers, but it's arguments like these in favor >>> that are making me increasingly wary. >> >> IMO it's not about reputation, it's about ease of use. A shorter ASN is easier to remember, say, and recognize. When I was setting up peering at a former job, we needed a new ASN for the peering network, and had a few unused ASNs to choose from. We chose the one that was easiest for humans (22212). If we could've easily acquired a 3-digit ASN instead, that would've been even better. >> >> There are fewer than 9999 companies doing peering at IXs, and likely fewer than 999 that have more than a few dozen peers. IMO there's no good reason any of them should have to use a hard-to-remember random 5-digit ASN for peering if they don't want to. >> >> -Scott > > This Human Factors based argument makes sense to me. It is on par with making IPv6 allocations on nibble boundaries and the fact that IPv6 has zero suppression, because they also makes things easier for Humans. Until the Internet starts building itself, Human Factors are always going to be an issue to some degree or another. > > Number are just numbers to computers. However, when Humans interact with the numbers as part of the system, smaller or easy to remember longer sequences will be better and less likely to cause transcription or other Human based errors. While the human factors argument Scott raises is the first argument in this thread that is at all persuasive in favor of the proposal, I still feel that the intended misperception, vanity, and other arguments actually carry the day and I remain unconvinced that this proposal has more merit than disadvantage. As an amusing side-note, in my days of configuring peering sessions with Scott's former employer, AS22212 was one of the ones I was most likely to have to re-enter into configurations due to typographical errors (often being mis-entered as 22122). Owen From ppml at rs.seastrom.com Mon Apr 2 16:27:28 2012 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 02 Apr 2012 16:27:28 -0400 Subject: [arin-ppml] DRAFT POLICY 2012-3: ASN TRANSFERS In-Reply-To: (Owen DeLong's message of "Mon, 2 Apr 2012 12:42:13 -0700") References: <1120330112006.56017D-100000@Ives.egh.com> <0AE39222-F337-45DE-B3E3-91A7B9F23E05@gmail.com> <4F75DF15.7060509@burnttofu.net> <21CD3214-FEA6-44A5-AFE5-47CBF579F962@gmail.com> <4F762804.6070100@umn.edu> Message-ID: <86398ldglr.fsf@seastrom.com> Owen DeLong writes: > As an amusing side-note, in my days of configuring peering sessions > with Scott's former employer, AS22212 was one of the ones I was most > likely to have to re-enter into configurations due to typographical > errors (often being mis-entered as 22122). Wouldn't have been a problem if they'd had a single digit ASN now, would it? :) -r From heather.skanks at gmail.com Thu Apr 5 16:09:35 2012 From: heather.skanks at gmail.com (Heather Schiller) Date: Thu, 5 Apr 2012 16:09:35 -0400 Subject: [arin-ppml] Draft Policy 2012-2: IPv6 Subsequent Allocations Utilization Requirement In-Reply-To: <4F49A296.5090503@arin.net> References: <4F49A296.5090503@arin.net> Message-ID: I am working on final text and prepping slides for the meeting in a few weeks. Does anyone have any feedback on this policy or on the staff feedback? The goal is to be able to get a subsequent allocation when, partway through deploying, you realize you don't have enough room to subnet. I would really like to hear from people who have encountered this problem and what their assignment vs subnet utilization was. I don't expect the "1* customer or infrastructure allocation or assignment" to hold -- I would like to hear what reasonable number 1 could be replaced with. 10? 20? 50? Should there be some bounds that could be put around what a reasonable subnet size is, so that you can't game the process by creating large, empty subnets? Or is subnet size too unique to the network? Thanks, --Heather Proposal text: Modify 6.5.3.b as follows: An LIR may request a subsequent allocation when they can show utilization of: 75% or more of their total address space or more than 90% of any serving site or when 75% of the aggregate has been subnetted, and each subnet contains at least 1* customer or infrastructure allocation or assignment ( *1 can be replaced here with any reasonable number) On Sat, Feb 25, 2012 at 10:10 PM, ARIN wrote: > Correction. Earlier post did not use updated policy text. > > Draft Policy ARIN-2012-2 > IPv6 Subsequent Allocations Utilization Requirement > > On 16 February 2012 the ARIN Advisory Council (AC) selected "Clarifying > requirements for IPv4 transfers" as a ?draft policy for adoption discussion > on the PPML and at the Public Policy Meeting in Vancouver in April. > > The draft was developed by the AC from policy proposal "ARIN-prop-159 IPv6 > Subsequent Allocations Utilization Requirement." Per the Policy Development > Process the AC submitted text to ARIN for a staff and legal assessment prior > to its selection as a draft policy. Below the draft policy is the ARIN staff > and legal assessment, followed by the text that was submitted by the AC. > > Draft Policy ARIN-2012-2 is below and can be found at: > https://www.arin.net/policy/proposals/2012_2.html > > You are encouraged to discuss Draft Policy 2012-2 on the PPML prior to > the April Public Policy Meeting. Both the discussion on the list and > at the meeting will be used by the ARIN Advisory Council to determine > the community consensus for adopting this as policy. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2012-2 > IPv6 Subsequent Allocations Utilization Requirement > > Date: 22 February 2012 > > Policy statement: > > Proposal text: > Modify 6.5.3.b as follows: > An LIR may request a subsequent allocation when they can show utilization > of: > 75% or more of their total address space > ?or > more than 90% of any serving site > ?or > when 75% of the aggregate has been subnetted, and each subnet contains at > least 1* customer or infrastructure allocation or assignment > ?( *1 can be replaced here with any reasonable number) > > Original Rationale: > > If you are executing to a long term plan, you should be able to continue to > execute on your approved allocation and assignment plan regardless of the > number of regions/groupings you originally planned for. We want to promote > tie downs on nibbles and long term planning. > > Timetable for implementation: Immediately > > > ########## > > > ARIN Staff and Legal Assessment > > Draft Policy: ?PP 159 ?IPv6 Subsequent Allocations Utilization Requirement? > Date of Assessment: ?15 Feb 2012 > 1. ?Proposal Summary (Staff Understanding) > > The intent of this proposal is to allow an additional way for ISP's that > have already begun using their IPv6 space but who may not have sufficiently > planned for longer term growth, to receive an additional allocation. ? This > policy would allow an organization to qualify for an additional IPv6 > allocation if they can show that 75% of their IPv6 address space as a whole > is subnetted, provided that each subnet has at least 1 customer or > infrastructure assignment/allocation. > > 2. Staff Comments: > > A. ARIN Staff Comments: > > If this policy were to be implemented exactly as written, ARIN staff would > approve an additional IPv6 allocation as long as a network had subnetted at > least 75% of their IPv6 allocation, with at least one customer or internal > assignment/allocation in each subnet. ?ARIN would not evaluate subnet size; > as long as any portion of a subnet is used, then that subnet would be > considered to be fully used, regardless of its size. ?Effectively, this > allows an operator to qualify for IPv6 addresses any time they want, because > it's trivial to subnet out 75% of an allocation(s) and use at least a tiny > portion of each, and may not encourage conservation of IPv6 address space. > > If the author's intent is to allow operators to make reasonable decisions > about their IPv6 deployment, another option would be to simplify the IPv6 > additional allocation policy to allow an operator to qualify for more IPv6 > addresses when they can show a need for them. > > Alternatively, if the author's intent is to have ARIN staff evaluate whether > those decisions are reasonable, then specific criteria needs to be laid out > to give staff guidance as to how we do that (e.g. block size, timeframes, > etc.). > The author's original proposal rationale stated that the expectation would > be for ARIN to use its discretion to weed out such requests, but there is no > policy basis for doing so. ?Nothing in this text gives staff any basis for > rejecting any subnet size, regardless of how reasonable we think it is. > ?If the author wants ARIN to review requests to determine if technically > reasonable, than some criteria or guidance must be provided within the > policy text. > > B. ARIN General Counsel ? > > This policy does not create significant legal issues. > > 3. Resource Impact > > This policy would have minimal resource impact from an implementation > aspect. ?It is estimated that implementation could occur within 3 months > after ratification by the ARIN Board of Trustees. > > The following would be needed in order to implement: > > Guidelines and procedures need to be updated > Staff training > > Proposal text: > Modify 6.5.3.b as follows: > An LIR may request a subsequent allocation when they can show utilization > of: > 75% or more of their total address space > ?or > more than 90% of any serving site > ?or > when 75% of the aggregate has been subnetted, and each subnet contains at > least 1* customer or infrastructure allocation or assignment > ?( *1 can be replaced here with any reasonable number) > > Original Rationale: > > If you are executing to a long term plan, you should be able to continue to > execute on your approved allocation and assignment plan regardless of the > number of regions/groupings you originally planned for. We want to promote > tie downs on nibbles and long term planning. > > > _______________________________________________ > 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 Thu Apr 5 16:56:17 2012 From: bill at herrin.us (William Herrin) Date: Thu, 5 Apr 2012 16:56:17 -0400 Subject: [arin-ppml] Draft Policy 2012-2: IPv6 Subsequent Allocations Utilization Requirement In-Reply-To: References: <4F49A296.5090503@arin.net> Message-ID: On Thu, Apr 5, 2012 at 4:09 PM, Heather Schiller wrote: > I am working on final text and prepping slides for the meeting in a > few weeks. ?Does anyone have any feedback on this policy or on the > staff feedback? Hi Heather, On the one hand, I'm in favor of a pro-forma approval of an ISP's second IPv6 request so long as it is not outrageously sized (for "outrage" in the bigger than /24 category). Time enough to make tight IPv6 allocation rules when we have the experience which goes with half of the packets on the Internet moving with IPv6. On the other hand, the text as written seems contrived. The following subnetting scheme appears to qualify: Original /32 allocation: /33 to Minneapolis POP 1 customer /48 /34 to Saint Paul POP 1 customer /48 3 ISP corporate LANs, /48 each Woohoo, 75.0046% utilization! Block #2, here I come. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tvest at eyeconomics.com Thu Apr 5 16:59:14 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Thu, 5 Apr 2012 16:59:14 -0400 Subject: [arin-ppml] [address-policy-wg] On use of the word "sold" (was: 2012-01 New Policy Proposal (Inter-RIR IPv4 Address Transfers)) In-Reply-To: References: <0231863C-878F-4525-AA1E-AC3C221747FF@corp.arin.net> <4F7C6EC7.7030701@consol.net> <3A5A9D3C-A4A2-4675-B817-7604AF26E91B@baycix.de> <36D7FC27-F306-4CB5-90E8-14962D375979@corp.arin.net> <438F51C3-210A-470B-BFEE-CE9ED2E59952@virtualized.org> Message-ID: On Apr 5, 2012, at 3:50 PM, David Conrad wrote: > On Apr 5, 2012, at 10:16 AM, John Curran wrote: >>> well, at first, just to state the obvious once more >>> >>> a) For RIR-managed resources... >>> >>> ...this is basically true. >>> >>> b) For pre-RIR resources... >>> >>> ...RIR policies cannot be applied. Anyone can really sell this stuff, they seem to really own those. >> >> That may be regional difference (or not), as in the ARIN region >> we run a single registry with a single set of policies which >> apply to all resources. > > Which is, of course, not particularly relevant to the question of whether resources can be bought or sold. It is only relevant to whether or not ARIN will update their registry to reflect reality in their "single registry". > > It would seem ARIN has decided that accuracy of registration data is secondary to conformance to "consensus" policy. I hope RIPE does not follow ARIN down that particular path as such an approach would appear to strongly encourage the proliferation of registration information databases which will undoubtedly result in challenges in network operations. I do not believe registration information databases should be used as a weapon to try to force compliance to policy. > > Regards, > -drc On Apr 5, 2012, at 4:02 PM, John Curran wrote: > On Apr 5, 2012, at 3:50 PM, David Conrad wrote: > >> It would seem ARIN has decided that accuracy of registration data is secondary to conformance to "consensus" policy. I hope RIPE does not follow ARIN down that particular path as such an approach would appear to strongly encourage the proliferation of registration information databases which will undoubtedly result in challenges in network operations. > > So far it hasn't been a problem, but that's best a > discussion for mailing lists back in the ARIN region. > > FYI, > /John > > John Curran > President and CEO > ARIN Hi David, Based on the statement above, it would seem that given the choice between (a) a single standard-ized registry, i.e., where participation in the registry is conditional on both (actively or passively) *contributing to* and *abiding by* participant-defined policies -- and (b) a registry which is unencumbered by any binding standards at all, and thus empowers individual participants to unilaterally assert "as reality" whatever seems appropriate to them at any given time, you would strongly prefer the latter? If this is correct, could you explain the basis for your preference? Do you believe that, under (a), the rate of deviation from "reality" (or the decline in registry usefulness) e.g., due to registry defections, etc., would be greater than the rate under (b) at which the selective "customization" of registry entries would erode the very notion a shared "reality" (at least for operational purposes)? Given the fact that your position seems to absolutely entail (b), at least for transferred resources, what if anything leads you to believe that the the effects of such a policy change would not cause other registry members to promptly exercise the same prerogative and/or to simply exit when the resulting degradation in registry data quality becomes apparent? Genuinely curious, TV From narten at us.ibm.com Fri Apr 6 00:53:02 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 06 Apr 2012 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201204060453.q364r2uu012687@rotala.raleigh.ibm.com> Total of 25 messages in the last 7 days. script run at: Fri Apr 6 00:53:02 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 16.00% | 4 | 20.37% | 42785 | tvest at eyeconomics.com 16.00% | 4 | 13.93% | 29260 | snowhorn at gmail.com 8.00% | 2 | 9.46% | 19875 | heather.skanks at gmail.com 8.00% | 2 | 5.80% | 12187 | michael+ppml at burnttofu.net 4.00% | 1 | 7.76% | 16302 | hannigan at gmail.com 4.00% | 1 | 6.02% | 12653 | kkargel at polartel.com 4.00% | 1 | 4.31% | 9046 | jeffrey.lyon at blacklotus.net 4.00% | 1 | 4.14% | 8690 | adudek16 at gmail.com 4.00% | 1 | 4.01% | 8418 | farmer at umn.edu 4.00% | 1 | 3.81% | 8006 | owen at delong.com 4.00% | 1 | 3.48% | 7307 | narten at us.ibm.com 4.00% | 1 | 3.23% | 6794 | scottleibrand at gmail.com 4.00% | 1 | 3.10% | 6501 | bill at herrin.us 4.00% | 1 | 2.87% | 6027 | john at egh.com 4.00% | 1 | 2.76% | 5791 | jcurran at arin.net 4.00% | 1 | 2.55% | 5361 | ppml at rsuc.gweep.net 4.00% | 1 | 2.40% | 5039 | ppml at rs.seastrom.com --------+------+--------+----------+------------------------ 100.00% | 25 |100.00% | 210042 | Total From mueller at syr.edu Mon Apr 9 11:09:07 2012 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 9 Apr 2012 15:09:07 +0000 Subject: [arin-ppml] FW: In favor of 2012-01 In-Reply-To: <855077AC3D7A7147A7570370CA01ECD2103DE3@SUEX10-mbx-10.ad.syr.edu> References: <855077AC3D7A7147A7570370CA01ECD2103DE3@SUEX10-mbx-10.ad.syr.edu> Message-ID: <855077AC3D7A7147A7570370CA01ECD2106BDB@SUEX10-mbx-10.ad.syr.edu> The following message was sent to RIPE's address policy list last week in connection with the discussion of its inter-regional transfer policy proposal, but apparently has been censored. I copy it here because the discussion is relevant to all regions. Anyone who knows who "moderates" RIPE's list might want to bring this problem to their attention. -----Original Message----- From: Milton L Mueller Sent: Thursday, April 05, 2012 4:12 PM To: address-policy-wg at ripe.net Subject: In favor of 2012-01 > -----Original Message----- > > this is exactly the problem. this implies that the ip space is an asset of the > seller, which it is not. it is a commons, and if it is sparse, as any one has the > same right to it, it is to be redistributed according to need, fair and equally. The IP address space is not and never has been a commons. Not for those of us who actually understand the vocabulary of resource economics and know what the term "commons" means. For IP addresses to be a "commons" they all would have to be available for use for anyone at any time; i.e., there would have to be no exclusive occupation of it. And of course that doesn't work technically, does it? IP address blocks have to be uniquely and exclusively assigned to specific users to function on the internet. Which means the address pool is not a commons - end of story, full stop, that's it. Because IP addresses are exclusively assigned, they can in fact be governed either as common pool resources (in which a governance agency establishes rules regulating the extraction of resource units from a pool) or as tradeable property (in which holders allocate the resources by making trades among themselves). All that matters is which method is more efficient and produces more benefits for Internet users. Leave your religious beliefs in your prayer chapels. > the problem is not that space is transfered. the problem is that the seller > assumes that he has the (absolute) power over it, that it is his own, even if > the requirements that lead to the allocation or assignment to him isn't valid > anymore. If you think that is wrong, apparently you haven't noticed the last 10 years of IP address allocation. RIPE and the other RIRs lack the resources to constantly monitor the efficiency and need of specific holders of address blocks _after_ they are allocated and assigned, and they also lack the authority to reclaim resources that they deem are underutilized. In the RIR's common pool governance, resources go out but they rarely, practically never, come back. (It's a reverse roach motel. They check out, but they never check back in.) Apparently, everyone who holds a block already thinks that it's an asset. What a surprise! Not. It is a valuable asset, given that it must be exclusively held and you can't do Internet business without it in appropriate quantities. I can't think of a better definition of an asset than something that is scarce, exclusively held, and essential to operations. Therefore, post-IPv4 exhaustion, common pool governance breaks down completely and the best way to ensure efficient utilization of remaining v4 resources is to allow market-based transfers. These transfers should be made as flexible and easy as possible. There is probably no need for holding periods, although they don't seem to do a lot of harm as long as they are 1 year or less. Needs assessment is increasingly arbitrary and pointless in such an environment. I know needs-basis is another item of religious faith in these circles, but the idea that RIR staff can accurately assess "need" given inherent uncertainty about time horizons and technical development, is just wrong. Organizations should be allowed to buy as much of an asset as they think they need, and can afford, in order to advance their business interests. Let the price system sort out who really needs what. It should also be obvious that the market for these addresses should be global, not regional. Thus, I support proposed policy 2012-01, my only reservation being that the 15 month resale restriction is too long, but again, that is not a fatal flaw as I suspect that any serious purchaser of address blocks will be holding on to them naturally for far longer. From ppml at rs.seastrom.com Mon Apr 9 11:36:08 2012 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 09 Apr 2012 11:36:08 -0400 Subject: [arin-ppml] FW: In favor of 2012-01 In-Reply-To: <855077AC3D7A7147A7570370CA01ECD2106BDB@SUEX10-mbx-10.ad.syr.edu> (Milton L. Mueller's message of "Mon, 9 Apr 2012 15:09:07 +0000") References: <855077AC3D7A7147A7570370CA01ECD2103DE3@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2106BDB@SUEX10-mbx-10.ad.syr.edu> Message-ID: <86398cc3yv.fsf@seastrom.com> Hi Milton, Just to clarify and reinforce (and avoid any confusion due to unfortunate namespace collision in the way we number our policy proposals), the commentary infra relates to: http://www.ripe.net/ripe/policies/proposals/2012-01 as opposed to https://www.arin.net/policy/proposals/2012_1.html correct? thanks, -r Milton L Mueller writes: > The following message was sent to RIPE's address policy list last week in connection with the discussion of its inter-regional transfer policy proposal, but apparently has been censored. I copy it here because the discussion is relevant to all regions. Anyone who knows who "moderates" RIPE's list might want to bring this problem to their attention. > > -----Original Message----- > From: Milton L Mueller > Sent: Thursday, April 05, 2012 4:12 PM > To: address-policy-wg at ripe.net > Subject: In favor of 2012-01 > > > >> -----Original Message----- >> >> this is exactly the problem. this implies that the ip space is an asset of the >> seller, which it is not. it is a commons, and if it is sparse, as any one has the >> same right to it, it is to be redistributed according to need, fair and equally. > > The IP address space is not and never has been a commons. Not for those of us who actually understand the vocabulary of resource economics and know what the term "commons" means. > For IP addresses to be a "commons" they all would have to be available for use for anyone at any time; i.e., there would have to be no exclusive occupation of it. And of course that doesn't work technically, does it? IP address blocks have to be uniquely and exclusively assigned to specific users to function on the internet. Which means the address pool is not a commons - end of story, full stop, that's it. > > Because IP addresses are exclusively assigned, they can in fact be governed either as common pool resources (in which a governance agency establishes rules regulating the extraction of resource units from a pool) or as tradeable property (in which holders allocate the resources by making trades among themselves). All that matters is which method is more efficient and produces more benefits for Internet users. Leave your religious beliefs in your prayer chapels. > >> the problem is not that space is transfered. the problem is that the seller >> assumes that he has the (absolute) power over it, that it is his own, even if >> the requirements that lead to the allocation or assignment to him isn't valid >> anymore. > > If you think that is wrong, apparently you haven't noticed the last 10 years of IP address allocation. > > RIPE and the other RIRs lack the resources to constantly monitor the efficiency and need of specific holders of address blocks _after_ they are allocated and assigned, and they also lack the authority to reclaim resources that they deem are underutilized. In the RIR's common pool governance, resources go out but they rarely, practically never, come back. (It's a reverse roach motel. They check out, but they never check back in.) Apparently, everyone who holds a block already thinks that it's an asset. What a surprise! Not. It is a valuable asset, given that it must be exclusively held and you can't do Internet business without it in appropriate quantities. I can't think of a better definition of an asset than something that is scarce, exclusively held, and essential to operations. > > Therefore, post-IPv4 exhaustion, common pool governance breaks down completely and the best way to ensure efficient utilization of remaining v4 resources is to allow market-based transfers. These transfers should be made as flexible and easy as possible. There is probably no need for holding periods, although they don't seem to do a lot of harm as long as they are 1 year or less. Needs assessment is increasingly arbitrary and pointless in such an environment. I know needs-basis is another item of religious faith in these circles, but the idea that RIR staff can accurately assess "need" given inherent uncertainty about time horizons and technical development, is just wrong. Organizations should be allowed to buy as much of an asset as they think they need, and can afford, in order to advance their business interests. Let the price system sort out who really needs what. > > It should also be obvious that the market for these addresses should be global, not regional. > > Thus, I support proposed policy 2012-01, my only reservation being that the 15 month resale restriction is too long, but again, that is not a fatal flaw as I suspect that any serious purchaser of address blocks will be holding on to them naturally for far longer. > > > _______________________________________________ > 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 dogwallah at gmail.com Mon Apr 9 15:19:28 2012 From: dogwallah at gmail.com (McTim) Date: Mon, 9 Apr 2012 19:19:28 +0000 Subject: [arin-ppml] FW: In favor of 2012-01 In-Reply-To: <855077AC3D7A7147A7570370CA01ECD2106BDB@SUEX10-mbx-10.ad.syr.edu> References: <855077AC3D7A7147A7570370CA01ECD2103DE3@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2106BDB@SUEX10-mbx-10.ad.syr.edu> Message-ID: Milton, AFAIK none of the RIRS policy lists are moderated, perhaps you should check to see if you are actually subscribed to the list with the email address you used. You can check your subscription here: http://www.ripe.net/mailman/listinfo/address-policy-wg/ On Monday, April 9, 2012, Milton L Mueller wrote: > The following message was sent to RIPE's address policy list last week in > connection with the discussion of its inter-regional transfer policy > proposal, but apparently has been censored. I copy it here because the > discussion is relevant to all regions. Anyone who knows who "moderates" > RIPE's list might want to bring this problem to their attention. > > -----Original Message----- > From: Milton L Mueller > Sent: Thursday, April 05, 2012 4:12 PM > To: address-policy-wg at ripe.net > Subject: In favor of 2012-01 > > > > > -----Original Message----- > > > > this is exactly the problem. this implies that the ip space is an asset > of the > > seller, which it is not. it is a commons, and if it is sparse, as any > one has the > > same right to it, it is to be redistributed according to need, fair and > equally. > > The IP address space is not and never has been a commons. Not for those of > us who actually understand the vocabulary of resource economics and know > what the term "commons" means. > For IP addresses to be a "commons" they all would have to be available for > use for anyone at any time; i.e., there would have to be no exclusive > occupation of it. And of course that doesn't work technically, does it? There are lots of folks who number their internal networks using addresses that haven't been allocated or assigned to them, and, while not BCP, it seems to work for them. > How is applying policy uniformly arbitrary? > IP address blocks have to be uniquely and exclusively assigned to specific > users to function on the internet. Which means the address pool is not a > commons - end of story, full stop, that's it. > > Because IP addresses are exclusively assigned, they can in fact be > governed either as common pool resources (in which a governance agency > establishes rules regulating the extraction of resource units from a pool) > or as tradeable property (in which holders allocate the resources by making > trades among themselves). All that matters is which method is more > efficient and produces more benefits for Internet users. Leave your > religious beliefs in your prayer chapels. > > > the problem is not that space is transfered. the problem is that the > seller > > assumes that he has the (absolute) power over it, that it is his own, > even if > > the requirements that lead to the allocation or assignment to him isn't > valid > > anymore. > > If you think that is wrong, apparently you haven't noticed the last 10 > years of IP address allocation. > > RIPE and the other RIRs lack the resources to constantly monitor the > efficiency and need of specific holders of address blocks _after_ they are > allocated and assigned, and they also lack the authority to reclaim > resources that they deem are underutilized. In the RIR's common pool > governance, resources go out but they rarely, practically never, come back. > You might be surprised at how often blocks are returned. ARIN staff can probably give us the raw numbers of returns over the last decade if we ask nicely. > > (It's a reverse roach motel. They check out, but they never check back > in.) Apparently, everyone who holds a block already thinks that it's an > asset. What a surprise! Not. It is a valuable asset, given that it must be > exclusively held and you can't do Internet business without it in > appropriate quantities. I can't think of a better definition of an asset > than something that is scarce, exclusively held, and essential to > operations. > > Therefore, post-IPv4 exhaustion, common pool governance breaks down > completely and the best way to ensure efficient utilization of remaining v4 > resources is to allow market-based transfers. These transfers should be > made as flexible and easy as possible. There is probably no need for > holding periods, although they don't seem to do a lot of harm as long as > they are 1 year or less. Needs assessment is increasingly arbitrary and > pointless in such an environment. I know needs-basis is another item of > religious faith in these circles, but the idea that RIR staff can > accurately assess "need" given inherent uncertainty about time horizons and > technical development, Is wrong. > Organizations should be allowed to buy as much of an asset as they think > they need, and can afford, in order to advance their business interests. > Let the price system sort out who really needs what. Hmmm, isn't this a recipe to invite hoarding and speculation? Rgds, McTim > > > > > _______________________________________________ > 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. > -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel -------------- next part -------------- An HTML attachment was scrubbed... URL: From nigel at titley.com Tue Apr 10 12:02:46 2012 From: nigel at titley.com (Nigel Titley) Date: Tue, 10 Apr 2012 17:02:46 +0100 Subject: [arin-ppml] FW: In favor of 2012-01 In-Reply-To: <855077AC3D7A7147A7570370CA01ECD2106BDB@SUEX10-mbx-10.ad.syr.edu> References: <855077AC3D7A7147A7570370CA01ECD2103DE3@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2106BDB@SUEX10-mbx-10.ad.syr.edu> Message-ID: <4F8459A6.9010803@titley.com> Milton I'm checking this out. Nigel On 09/04/2012 16:09, Milton L Mueller wrote: > The following message was sent to RIPE's address policy list last week in connection with the discussion of its inter-regional transfer policy proposal, but apparently has been censored. I copy it here because the discussion is relevant to all regions. Anyone who knows who "moderates" RIPE's list might want to bring this problem to their attention. > > -----Original Message----- > From: Milton L Mueller > Sent: Thursday, April 05, 2012 4:12 PM > To: address-policy-wg at ripe.net > Subject: In favor of 2012-01 > > > >> -----Original Message----- >> >> this is exactly the problem. this implies that the ip space is an asset of the >> seller, which it is not. it is a commons, and if it is sparse, as any one has the >> same right to it, it is to be redistributed according to need, fair and equally. > The IP address space is not and never has been a commons. Not for those of us who actually understand the vocabulary of resource economics and know what the term "commons" means. > For IP addresses to be a "commons" they all would have to be available for use for anyone at any time; i.e., there would have to be no exclusive occupation of it. And of course that doesn't work technically, does it? IP address blocks have to be uniquely and exclusively assigned to specific users to function on the internet. Which means the address pool is not a commons - end of story, full stop, that's it. > > Because IP addresses are exclusively assigned, they can in fact be governed either as common pool resources (in which a governance agency establishes rules regulating the extraction of resource units from a pool) or as tradeable property (in which holders allocate the resources by making trades among themselves). All that matters is which method is more efficient and produces more benefits for Internet users. Leave your religious beliefs in your prayer chapels. > >> the problem is not that space is transfered. the problem is that the seller >> assumes that he has the (absolute) power over it, that it is his own, even if >> the requirements that lead to the allocation or assignment to him isn't valid >> anymore. > If you think that is wrong, apparently you haven't noticed the last 10 years of IP address allocation. > > RIPE and the other RIRs lack the resources to constantly monitor the efficiency and need of specific holders of address blocks _after_ they are allocated and assigned, and they also lack the authority to reclaim resources that they deem are underutilized. In the RIR's common pool governance, resources go out but they rarely, practically never, come back. (It's a reverse roach motel. They check out, but they never check back in.) Apparently, everyone who holds a block already thinks that it's an asset. What a surprise! Not. It is a valuable asset, given that it must be exclusively held and you can't do Internet business without it in appropriate quantities. I can't think of a better definition of an asset than something that is scarce, exclusively held, and essential to operations. > > Therefore, post-IPv4 exhaustion, common pool governance breaks down completely and the best way to ensure efficient utilization of remaining v4 resources is to allow market-based transfers. These transfers should be made as flexible and easy as possible. There is probably no need for holding periods, although they don't seem to do a lot of harm as long as they are 1 year or less. Needs assessment is increasingly arbitrary and pointless in such an environment. I know needs-basis is another item of religious faith in these circles, but the idea that RIR staff can accurately assess "need" given inherent uncertainty about time horizons and technical development, is just wrong. Organizations should be allowed to buy as much of an asset as they think they need, and can afford, in order to advance their business interests. Let the price system sort out who really needs what. > > It should also be obvious that the market for these addresses should be global, not regional. > > Thus, I support proposed policy 2012-01, my only reservation being that the 15 month resale restriction is too long, but again, that is not a fatal flaw as I suspect that any serious purchaser of address blocks will be holding on to them naturally for far longer. > > > _______________________________________________ > 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 Daniel_Alexander at Cable.Comcast.com Wed Apr 11 23:01:01 2012 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Thu, 12 Apr 2012 03:01:01 +0000 Subject: [arin-ppml] ARIN-2012-1: Clarifying requirements for IPv4 transfers Message-ID: Here is the final 2012-1 text for the meeting in Vancouver. I am working on presentation slides so let me know if you have any feedback or thoughts that should be clarified during the meeting discussion. This text includes the word "transfers" in the 12 month restriction window placed on the source. This change was the result of previous mailing list discussions and feedback from Staff. Thanks, Dan Final text: 2012-1: Clarifying requirements for IPv4 transfers Replace Section 8.3 with 8.3 Transfers between Specified Recipients within the ARIN Region. In addition to transfers under section 8.2, IPv4 numbers resources may be transferred according to the following conditions. Conditions on source of the transfer: * The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. * The source entity will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. * The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers. * The minimum transfer size is a /24 Conditions on recipient of the transfer: * The recipient must demonstrate the need for up to a 24 month supply of IP address resources under current ARIN policies and sign an RSA. * The resources transferred will be subject to current ARIN policies. Add Section 8.4 Inter-RIR Transfers to Specified Recipients Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies. Conditions on source of the transfer: * The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources. * Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration. * Source entities within the ARIN region will not be eligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. * Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers. * The minimum transfer size is a /24. Conditions on recipient of the transfer: * The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR. * Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received. * Recipients within the ARIN region must demonstrate the need for up to a 24 month supply of IPv4 address space. * The minimum transfer size is a /24 Rationale: The original text of this proposal attempted to clarify the requirements of an IPv4 address transfer while protecting any resources remaining in the ARIN free pool. This revision is a result of feedback from the mailing list, ARIN Staff, and discussions with the original author. The one key point that has been removed from the original text is that a needs based review remains in place. The current text attempts to retain the original concepts of protecting an ARIN free pool, and incorporating it with the point of bringing resources under RSA. The resulting text attempts to put safeguards in place on the practice of paid transfers by creating a black out period for transfers and requests to the free pool. The text also tries to incorporate discussions regarding inter-RIR transfers and come up with language that includes the free pool protections for transfers in and out of the Region. Timetable for implementation: immediate. From Daniel_Alexander at Cable.Comcast.com Thu Apr 12 10:59:24 2012 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Thu, 12 Apr 2012 14:59:24 +0000 Subject: [arin-ppml] ARIN-2012-1: Clarifying requirements for IPv4 transfers In-Reply-To: Message-ID: Bill, Thank you for the feedback. My interpretation views the word from the perspective of the RIR responsible for the source resource. In the case of the ARIN region, the "dispute" could be a variance between who is trying to act as the source, and the organization that ARIN has recorded in WHOIS. The same would apply to resources coming from other regions from the perspective of that region. It could also apply to a case where an organization wanted to act as a source for a block that is registered correctly in WHOIS, but the resources are tied to a delinquent account. I will work on getting staff's opinion on this. -Dan From: Bill Darte > Date: Thu, 12 Apr 2012 04:53:07 -0700 To: Microsoft Office User > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] ARIN-2012-1: Clarifying requirements for IPv4 transfers Dan, Thanks for this.... Areas that are likely to be attacked (probably no too strong a term).... The term "dispute".....means what? Where would the dispute be evidenced..in court...on PPML...within/between the RIRs? Our old "share reciprocal, compatible, needs-based policies" will surely be divisive again. On Wed, Apr 11, 2012 at 8:01 PM, Alexander, Daniel > wrote: Here is the final 2012-1 text for the meeting in Vancouver. I am working on presentation slides so let me know if you have any feedback or thoughts that should be clarified during the meeting discussion. This text includes the word "transfers" in the 12 month restriction window placed on the source. This change was the result of previous mailing list discussions and feedback from Staff. Thanks, Dan Final text: 2012-1: Clarifying requirements for IPv4 transfers Replace Section 8.3 with 8.3 Transfers between Specified Recipients within the ARIN Region. In addition to transfers under section 8.2, IPv4 numbers resources may be transferred according to the following conditions. Conditions on source of the transfer: * The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. * The source entity will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. * The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers. * The minimum transfer size is a /24 Conditions on recipient of the transfer: * The recipient must demonstrate the need for up to a 24 month supply of IP address resources under current ARIN policies and sign an RSA. * The resources transferred will be subject to current ARIN policies. Add Section 8.4 Inter-RIR Transfers to Specified Recipients Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies. Conditions on source of the transfer: * The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources. * Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration. * Source entities within the ARIN region will not be eligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. * Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers. * The minimum transfer size is a /24. Conditions on recipient of the transfer: * The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR. * Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received. * Recipients within the ARIN region must demonstrate the need for up to a 24 month supply of IPv4 address space. * The minimum transfer size is a /24 Rationale: The original text of this proposal attempted to clarify the requirements of an IPv4 address transfer while protecting any resources remaining in the ARIN free pool. This revision is a result of feedback from the mailing list, ARIN Staff, and discussions with the original author. The one key point that has been removed from the original text is that a needs based review remains in place. The current text attempts to retain the original concepts of protecting an ARIN free pool, and incorporating it with the point of bringing resources under RSA. The resulting text attempts to put safeguards in place on the practice of paid transfers by creating a black out period for transfers and requests to the free pool. The text also tries to incorporate discussions regarding inter-RIR transfers and come up with language that includes the free pool protections for transfers in and out of the Region. Timetable for implementation: immediate. _______________________________________________ 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 Thu Apr 12 11:19:09 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 12 Apr 2012 08:19:09 -0700 Subject: [arin-ppml] ARIN-2012-1: Clarifying requirements for IPv4 transfers In-Reply-To: References: Message-ID: <4F86F26D.10503@matthew.at> On 4/11/2012 8:01 PM, Alexander, Daniel wrote: > Here is the final 2012-1 text for the meeting in Vancouver. I am working > on presentation slides so let me know if you have any feedback or thoughts > that should be clarified during the meeting discussion. This text includes > the word "transfers" in the 12 month restriction window placed on the > source. This change was the result of previous mailing list discussions > and feedback from Staff. > > Thanks, > Dan > > > Final text: 2012-1: Clarifying requirements for IPv4 transfers > > Replace Section 8.3 with > > 8.3 Transfers between Specified Recipients within the ARIN Region. > > In addition to transfers under section 8.2, IPv4 numbers resources may be > transferred according to the following conditions. > > Conditions on source of the transfer: > > * The source entity must be the current registered holder of the IPv4 > address resources, and not be involved in any dispute as to the status of > those resources. "any dispute as to the status"? I'm sure we can always find someone who disputes whether or not the source entity should have transferable space. This should be something more concrete like a way for ARIN to flag blocks where the ownership is in question. (As opposed to other disputes, like whether they should have received that much space, or should be voluntarily returning it to ARIN, or whether those resources are being used to send spam.) > * The source entity will be ineligible to receive any further IPv4 address > allocations or assignments from ARIN for a period of 12 months after a > transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever > occurs first. But one may trivially create additional legal entities that can receive space, so this is meaningless. Also, how is "exhaustion of ARIN's IPv4 space" defined? Does this mean that if ARIN runs out, but then someone gives ARIN back a /8, I can go apply for it right away because the trigger happened? > * The source entity must not have received a transfer, allocation, or > assignment of IPv4 number resources from ARIN for the 12 months prior to > the approval of a transfer request. This restriction does not include M&A > transfers. I suppose this is a good reason to keep the lawyers employed doing M&A transfers, as those are more valuable assets. (More specifically, what this means is that the resale value I keep on my books for a /20 that I got within the last 12 months via transfer, allocation, or assignment is zero but the resale value of one received via M&A transfer is the market price for /20s.) It also means that I should create multiple legal entities for receiving assignments, so that the timer doesn't keep resetting on the other space I've already received. And is this retroactive, so that if I've just received an allocation the day before the policy went into effect I'm not ineligible to be the source of the transfer? I suppose this is a feature for long-time holders, as their space is the only space that is available for transfer. Can we kick this up to 5 years to further restrict the sell side of the market? Should help keep the prices high at least. Matthew Kaufman From owen at delong.com Thu Apr 12 12:58:37 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 12 Apr 2012 09:58:37 -0700 Subject: [arin-ppml] ARIN-2012-1: Clarifying requirements for IPv4 transfers In-Reply-To: <4F86F26D.10503@matthew.at> References: <4F86F26D.10503@matthew.at> Message-ID: <96BECFBA-F7EA-4A64-BC51-E0BF75A292A6@delong.com> > >> * The source entity will be ineligible to receive any further IPv4 address >> allocations or assignments from ARIN for a period of 12 months after a >> transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever >> occurs first. > Also, how is "exhaustion of ARIN's IPv4 space" defined? Does this mean that if ARIN runs out, but then someone gives ARIN back a /8, I can go apply for it right away because the trigger happened? > Good catch. I don't beleive that the ARIN runout clause should exist here. I suggest deleting everything after the comma. >> * The source entity must not have received a transfer, allocation, or >> assignment of IPv4 number resources from ARIN for the 12 months prior to >> the approval of a transfer request. This restriction does not include M&A >> transfers. > > I suppose this is a good reason to keep the lawyers employed doing M&A transfers, as those are more valuable assets. (More specifically, what this means is that the resale value I keep on my books for a /20 that I got within the last 12 months via transfer, allocation, or assignment is zero but the resale value of one received via M&A transfer is the market price for /20s.) > > It also means that I should create multiple legal entities for receiving assignments, so that the timer doesn't keep resetting on the other space I've already received. > > And is this retroactive, so that if I've just received an allocation the day before the policy went into effect I'm not ineligible to be the source of the transfer? I suppose this is a feature for long-time holders, as their space is the only space that is available for transfer. Can we kick this up to 5 years to further restrict the sell side of the market? Should help keep the prices high at least. And people wonder why I say paid transfers are and have been problematic. Owen From Daniel_Alexander at Cable.Comcast.com Thu Apr 12 22:41:54 2012 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Fri, 13 Apr 2012 02:41:54 +0000 Subject: [arin-ppml] ARIN-2012-1: Clarifying requirements for IPv4 transfers In-Reply-To: <4F86F26D.10503@matthew.at> Message-ID: On 4/12/12 11:19 AM, "Matthew Kaufman" wrote: >On 4/11/2012 8:01 PM, Alexander, Daniel wrote: >> Here is the final 2012-1 text for the meeting in Vancouver. I am working >> on presentation slides so let me know if you have any feedback or >>thoughts >> that should be clarified during the meeting discussion. This text >>includes >> the word "transfers" in the 12 month restriction window placed on the >> source. This change was the result of previous mailing list discussions >> and feedback from Staff. >> >> Thanks, >> Dan >> >> >> Final text: 2012-1: Clarifying requirements for IPv4 transfers >> >> Replace Section 8.3 with >> >> 8.3 Transfers between Specified Recipients within the ARIN Region. >> >> In addition to transfers under section 8.2, IPv4 numbers resources may >>be >> transferred according to the following conditions. >> >> Conditions on source of the transfer: >> >> * The source entity must be the current registered holder of the IPv4 >> address resources, and not be involved in any dispute as to the status >>of >> those resources. > >"any dispute as to the status"? I'm sure we can always find someone who >disputes whether or not the source entity should have transferable >space. This should be something more concrete like a way for ARIN to >flag blocks where the ownership is in question. (As opposed to other >disputes, like whether they should have received that much space, or >should be voluntarily returning it to ARIN, or whether those resources >are being used to send spam.) [DA] What wording would you suggest as a replacement? The intention was focused on whether the source entity is in compliance with their agreements with ARIN, or another RIR. The word was not intended to meet everyones interpretation of how the space might be used. > >> * The source entity will be ineligible to receive any further IPv4 >>address >> allocations or assignments from ARIN for a period of 12 months after a >> transfer approval, or until the exhaustion of ARIN's IPv4 space, >>whichever >> occurs first. > >But one may trivially create additional legal entities that can receive >space, so this is meaningless. > >Also, how is "exhaustion of ARIN's IPv4 space" defined? Does this mean >that if ARIN runs out, but then someone gives ARIN back a /8, I can go >apply for it right away because the trigger happened? [DA] I am not opposed to striking the extra condition. Should it just be 12 months no matter what? Unfortunately, the change cannot happen at this point since we are now into the text freeze until the meeting. > >> * The source entity must not have received a transfer, allocation, or >> assignment of IPv4 number resources from ARIN for the 12 months prior to >> the approval of a transfer request. This restriction does not include >>M&A >> transfers. > >I suppose this is a good reason to keep the lawyers employed doing M&A >transfers, as those are more valuable assets. (More specifically, what >this means is that the resale value I keep on my books for a /20 that I >got within the last 12 months via transfer, allocation, or assignment is >zero but the resale value of one received via M&A transfer is the market >price for /20s.) > >It also means that I should create multiple legal entities for receiving >assignments, so that the timer doesn't keep resetting on the other space >I've already received. [DA] Do you think the restrictions in this proposal serve any benefit over the wording of the existing policy? The intent of the proposal is to offer some protections of the free pool. Do you think section 8.3 is fine as is? > >And is this retroactive, so that if I've just received an allocation the >day before the policy went into effect I'm not ineligible to be the >source of the transfer? I suppose this is a feature for long-time >holders, as their space is the only space that is available for >transfer. Can we kick this up to 5 years to further restrict the sell >side of the market? Should help keep the prices high at least. [DA] What would your preference be? My interpretation is that it is retroactive. > >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. From narten at us.ibm.com Fri Apr 13 00:53:02 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 13 Apr 2012 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201204130453.q3D4r2e0009941@rotala.raleigh.ibm.com> Total of 10 messages in the last 7 days. script run at: Fri Apr 13 00:53:02 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 30.00% | 3 | 35.66% | 37896 | daniel_alexander at cable.comcast.com 10.00% | 1 | 17.41% | 18502 | dogwallah at gmail.com 10.00% | 1 | 8.98% | 9540 | ppml at rs.seastrom.com 10.00% | 1 | 8.80% | 9349 | nigel at titley.com 10.00% | 1 | 8.70% | 9249 | mueller at syr.edu 10.00% | 1 | 7.26% | 7714 | matthew at matthew.at 10.00% | 1 | 6.61% | 7022 | narten at us.ibm.com 10.00% | 1 | 6.59% | 7007 | owen at delong.com --------+------+--------+----------+------------------------ 100.00% | 10 |100.00% | 106279 | Total From tvest at eyeconomics.com Fri Apr 13 15:56:26 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 13 Apr 2012 15:56:26 -0400 Subject: [arin-ppml] On "commons" and "common pool resources" [was "In favor of 2012-01"] In-Reply-To: <855077AC3D7A7147A7570370CA01ECD2106BDB@SUEX10-mbx-10.ad.syr.edu> References: <855077AC3D7A7147A7570370CA01ECD2103DE3@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2106BDB@SUEX10-mbx-10.ad.syr.edu> Message-ID: <626D8380-C30E-4B18-AB01-349A482416CC@eyeconomics.com> (With apologies to those who also subscribe to address-policy-wg at ripe.net) On Apr 9, 2012, at 11:09 AM, Milton L Mueller wrote: > The following message was sent to RIPE's address policy list last week in connection with the discussion of its inter-regional transfer policy proposal, but apparently has been censored. I copy it here because the discussion is relevant to all regions. Anyone who knows who "moderates" RIPE's list might want to bring this problem to their attention. > > -----Original Message----- > From: Milton L Mueller > Sent: Thursday, April 05, 2012 4:12 PM > To: address-policy-wg at ripe.net > Subject: In favor of 2012-01 >> this is exactly the problem. this implies that the ip space is an asset of the >> seller, which it is not. it is a commons, and if it is sparse, as any one has the >> same right to it, it is to be redistributed according to need, fair and equally. > > The IP address space is not and never has been a commons. Not for those of us who actually understand the vocabulary of resource economics and know what the term "commons" means. > For IP addresses to be a "commons" they all would have to be available for use for anyone at any time; i.e., there would have to be no exclusive occupation of it. And of course that doesn't work technically, does it? IP address blocks have to be uniquely and exclusively assigned to specific users to function on the internet. Which means the address pool is not a commons - end of story. Hi Milton, I appreciate that you're trying to educate the address policy community about a field of academic inquiry that some members may not be familiar with, but in your haste to scold I think you may have added more to confusion than clarity. If the goal was to inform, it probably would have made more sense to start out by highlighting the fact that Chris' claim was perfectly sensible with respect to "common pool resources" even if it might be somewhat inapt when describing the abstract class "commons" -- instead of just obliquely acknowledging that fact later, as you do below. Regardless, as Elinor Ostron said in her Annual IEA Hayek Memorial Lecture two weeks ago, there are many different kinds of "commons," just as there are many different kinds of markets and "command and control" mechanisms. > Because IP addresses are exclusively assigned, they can be governed either as common pool resources (in which a governance agency establishes rules regulating the extraction of resource units from a free pool) or as tradeable property (in which holders allocate the resources by making trades among themselves) or some combination of both. All that matters is which method is more efficient and produces more benefits for Internet users. For those who would like to learn more about the analytical framework that Milton is using here, I would recommend his very interesting 2007 paper, "Property and Commons in Internet Governance." [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1828102] FWIW, I think that this claim about governance alternatives is perfectly reasonable -- at least for the kind of discrete, self-contained, non-interactive common pool resources that scholars like Garret Hardin and Elinor Ostrum have written about so extensively -- e.g., grazing lands, forests, fisheries, and other things that are composed of divisible elements which, once fractional portions have been separated and possessed by individual private parties, both cease to be dependent for 100% of their value on all of the other fractional elements of that original common pool, and also cease to represent a potential threat to the value of all of the fractional portions that are held by *other* private parties. However, when it comes to the kind of "intrinsically interactive" or "network-dependent" common pool resources that *do* continue to be sensitively dependent, for better or worse, on their "sibling" resources even *after* they have been withdrawn from the common pool and are privately controlled (or "owned"), there really is no clear alternative. Granted, common pool resources of this particular type are rare, but IP addresses are not the first or the only resource of this kind. The common pool resource that we typically call "money," and in particular the ability of private parties to unilaterally impact that pool by creating or withdrawing "credit" is another. History has clearly demonstrated that treating common pool resources of this rather unusual kind as if they were a uncoordinated, freely tradable resource is not a very good idea; every past effort to replace coordination mechanisms for this kind of resource with pure voluntary market mechanisms has ended in failure, not infrequently accompanied by widespread immiseration. > Leave your religious beliefs behind. Yellow card. Do we really want to go down this path again Milton? May I suggest that you henceforth dispense with the old ideological warfare rhetoric, so that I don't have to help clarify the context? > But after IPv4 exhaustion, common pool governance of v4 space breaks down completely and the best way to ensure efficient utilization of remaining v4 resources is to allow market-based transfers. The first claim is speculative, and the second is just argument by assertion. > These transfers should be made as flexible and easy as possible. There is probably no need for holding periods, although they don't seem to do a lot of harm as long as they are 1 year or less. Needs assessment is increasingly arbitrary and pointless in such an environment. I know needs-basis is another item of religious faith in some circles, Second yellow card. > but the idea that RIR staff can accurately assess "need" given inherent uncertainty about time horizons and technical development, is just wrong. Organizations should be allowed to buy as much of an asset as they think they need, and can afford, in order to advance their business interests. Let the price system sort out who really needs what. While the price system is perhaps the best possible mechanism for allocating almost everything (other than network-dependent common pool resources), under certain circumstances it seems to work quite badly. Markets work great when they look like neutral auctions, where every bidder knows exactly what they're bidding for, all buyers and sellers have access to the same information about past and present prices, and no single party or group has enough market power to distort aggregate prices. That said, in markets where pricing information is never publicly disclosed and thus never available to anyone even in average/aggregate form, it's not even clear to me that talking about the "price mechanism" -- much less praising it as infallible -- makes sense. And matters are even worse in cases where the market that's hidden within such a "cloud of pricing unknowability" is dedicated to the trading of functional resources whose future function/value will continue to be sensitive to the future choices and non-trading behavior of the original seller (as well as every other potential sell-side market participant). Many of us are still suffering in one way or another from the damage caused by the implosion of the last market like this (i.e., for CDOs, CDSes, and other "interactive" synthetic financial instruments) -- do we really want to see our industry follow that path? FWIW, If there is a consensus that some kind of voluntary resource redistribution mechanism(s) are needed, and that they should provide the means to move resources between parties that are associated with different registries, then I believe that there may be a great deal to be learned from past academic research on resource economics, and from scholars like Milton, and Elinor Ostrom, and many others. IMO it would be prudent to consider a broad range perspectives on how different kinds of common pool resources respond to different kinds of governance regime modifications before contemplating any policy changes that may be difficult or impossible to reconsider after the fact. Speaking for myself alone, TV From info at arin.net Wed Apr 18 10:43:46 2012 From: info at arin.net (ARIN) Date: Wed, 18 Apr 2012 10:43:46 -0400 Subject: [arin-ppml] Open Policy Hour at ARIN XXIX Message-ID: <4F8ED322.1070801@arin.net> ARIN XXIX is only a few days away, so make sure you are ready. The Open Policy Hour (OPH) will take place Tuesday afternoon within the Public Policy Meeting. OPH is not for discussion of draft policies that are already on the ARIN XXIX agenda, but an open floor for new ideas and suggestions. If you have a policy idea on which you would like to receive feedback before submitting a proposal, seize this opportunity to present it to the ARIN community. Sign up by Friday, 20 April 2012 to ensure you will be able to take the microphone. Send an email to policy at arin.net with your name, organization, and a general description of the policy subject you wish to present. You do not need to have a formal presentation in order to participate. Signing up in advance is not required, but it allows us to confirm your turn to present. Hope to see you in Vancouver! Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From narten at us.ibm.com Fri Apr 20 00:53:02 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 20 Apr 2012 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201204200453.q3K4r2Nf006498@rotala.raleigh.ibm.com> Total of 2 messages in the last 7 days. script run at: Fri Apr 20 00:53:02 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 66.53% | 12970 | tvest at eyeconomics.com 50.00% | 1 | 33.47% | 6524 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 19494 | Total From Yi.Chu at sprint.com Mon Apr 23 17:21:50 2012 From: Yi.Chu at sprint.com (Chu, Yi [NTK]) Date: Mon, 23 Apr 2012 21:21:50 +0000 Subject: [arin-ppml] remote participation Jabber issue - RE: Open Policy Hour at ARIN XXIX Message-ID: I am having problem signing on to Jabber. I think my company firewall blocks external Jabber, and my PC is locked down that I can't even run GTalk. Is there another avenue for me? I wish ARIN does Jabber as a web application on arin.net. yi -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, April 18, 2012 10:44 AM To: arin-ppml at arin.net Subject: [arin-ppml] Open Policy Hour at ARIN XXIX ARIN XXIX is only a few days away, so make sure you are ready. The Open Policy Hour (OPH) will take place Tuesday afternoon within the Public Policy Meeting. OPH is not for discussion of draft policies that are already on the ARIN XXIX agenda, but an open floor for new ideas and suggestions. If you have a policy idea on which you would like to receive feedback before submitting a proposal, seize this opportunity to present it to the ARIN community. Sign up by Friday, 20 April 2012 to ensure you will be able to take the microphone. Send an email to policy at arin.net with your name, organization, and a general description of the policy subject you wish to present. You do not need to have a formal presentation in order to participate. Signing up in advance is not required, but it allows us to confirm your turn to present. Hope to see you in Vancouver! Regards, Communications and Member Services American Registry for Internet Numbers (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. ________________________________ This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From markk at arin.net Mon Apr 23 17:50:15 2012 From: markk at arin.net (Mark Kosters) Date: Mon, 23 Apr 2012 21:50:15 +0000 Subject: [arin-ppml] remote participation Jabber issue - RE: Open Policy Hour at ARIN XXIX In-Reply-To: Message-ID: Hi There are a lot of web-based clients out on the 'net. The documentation at https://www.arin.net/participate/meetings/ARIN-XXIX/remote.html#jabber mentions jwchat - www.jwchat.org. Follow the documentation, register your JID, and you will soon have access to the jabber rooms. Regards, Mark Kosters ARIN CTO On 4/23/12 2:21 PM, "Chu, Yi [NTK]" wrote: >I am having problem signing on to Jabber. I think my company firewall >blocks external Jabber, and my PC is locked down that I can't even run >GTalk. Is there another avenue for me? I wish ARIN does Jabber as a >web application on arin.net. > >yi > From John.Kuhn at ontario.ca Tue Apr 24 14:06:00 2012 From: John.Kuhn at ontario.ca (Kuhn, John (MGS)) Date: Tue, 24 Apr 2012 14:06:00 -0400 Subject: [arin-ppml] FW: remote participation Jabber issue - RE: Open Policy Hour at ARIN XXIX References: Message-ID: <258C60971045264D8696361D3B7FD7FB02EABA0C@CTSPITDCEMMVX24.cihs.ad.gov.on.ca> I am having problem signing on to Jabber John Kuhn ________________________________ From: arin-ppml-bounces at arin.net on behalf of Chu, Yi [NTK] Sent: Mon 4/23/2012 5:21 PM To: ARIN; arin-ppml at arin.net Subject: [arin-ppml] remote participation Jabber issue - RE: Open Policy Hour at ARIN XXIX I am having problem signing on to Jabber. I think my company firewall blocks external Jabber, and my PC is locked down that I can't even run GTalk. Is there another avenue for me? I wish ARIN does Jabber as a web application on arin.net. yi -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, April 18, 2012 10:44 AM To: arin-ppml at arin.net Subject: [arin-ppml] Open Policy Hour at ARIN XXIX ARIN XXIX is only a few days away, so make sure you are ready. The Open Policy Hour (OPH) will take place Tuesday afternoon within the Public Policy Meeting. OPH is not for discussion of draft policies that are already on the ARIN XXIX agenda, but an open floor for new ideas and suggestions. If you have a policy idea on which you would like to receive feedback before submitting a proposal, seize this opportunity to present it to the ARIN community. Sign up by Friday, 20 April 2012 to ensure you will be able to take the microphone. Send an email to policy at arin.net with your name, organization, and a general description of the policy subject you wish to present. You do not need to have a formal presentation in order to participate. Signing up in advance is not required, but it allows us to confirm your turn to present. Hope to see you in Vancouver! Regards, Communications and Member Services? American Registry for Internet Numbers (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. ________________________________ This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. _______________________________________________ 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 Jack.Stevens at CenturyLink.com Wed Apr 25 09:00:33 2012 From: Jack.Stevens at CenturyLink.com (Stevens, Jack F) Date: Wed, 25 Apr 2012 08:00:33 -0500 Subject: [arin-ppml] FW: remote participation Jabber issue - RE: Open Policy Hour at ARIN XXIX In-Reply-To: <258C60971045264D8696361D3B7FD7FB02EABA0C@CTSPITDCEMMVX24.cihs.ad.gov.on.ca> References: <258C60971045264D8696361D3B7FD7FB02EABA0C@CTSPITDCEMMVX24.cihs.ad.gov.on.ca> Message-ID: <220BC22F971BA74383FD58436F1446AA014511E597@PKDWES4V3.EQ.Intranet> I used to have that issue and swore at the company firewall; I found that the Pidgin client seems to have gotten me around most of the issues. Also, Xabber on Android will also work. Jack Stevens Senior Engineer DNS - Web Hosting - Email Hosting - AUP - Networks - ARIN DMR CenturyLink -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kuhn, John (MGS) Sent: Tuesday, April 24, 2012 2:06 PM To: arin-ppml at arin.net Subject: [arin-ppml] FW: remote participation Jabber issue - RE: Open Policy Hour at ARIN XXIX I am having problem signing on to Jabber John Kuhn ________________________________ From: arin-ppml-bounces at arin.net on behalf of Chu, Yi [NTK] Sent: Mon 4/23/2012 5:21 PM To: ARIN; arin-ppml at arin.net Subject: [arin-ppml] remote participation Jabber issue - RE: Open Policy Hour at ARIN XXIX I am having problem signing on to Jabber. I think my company firewall blocks external Jabber, and my PC is locked down that I can't even run GTalk. Is there another avenue for me? I wish ARIN does Jabber as a web application on arin.net. yi -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, April 18, 2012 10:44 AM To: arin-ppml at arin.net Subject: [arin-ppml] Open Policy Hour at ARIN XXIX ARIN XXIX is only a few days away, so make sure you are ready. The Open Policy Hour (OPH) will take place Tuesday afternoon within the Public Policy Meeting. OPH is not for discussion of draft policies that are already on the ARIN XXIX agenda, but an open floor for new ideas and suggestions. If you have a policy idea on which you would like to receive feedback before submitting a proposal, seize this opportunity to present it to the ARIN community. Sign up by Friday, 20 April 2012 to ensure you will be able to take the microphone. Send an email to policy at arin.net with your name, organization, and a general description of the policy subject you wish to present. You do not need to have a formal presentation in order to participate. Signing up in advance is not required, but it allows us to confirm your turn to present. Hope to see you in Vancouver! Regards, Communications and Member Services? American Registry for Internet Numbers (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. ________________________________ This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. _______________________________________________ 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 bill at herrin.us Thu Apr 26 16:36:01 2012 From: bill at herrin.us (William Herrin) Date: Thu, 26 Apr 2012 16:36:01 -0400 Subject: [arin-ppml] Revealing /32 customers? Message-ID: Hi folks, Paraphrasing a private message I received during a recent NANOG discussion: "We have roughly 66 /32 customer assignments and a /24 for management addresses (switches, waps, wireless backhauls, servers, etc). Also a number of large assignments to DHCP pools. ARIN not only asked for the 66 customer names once, when the company went back to ask for additional space after renumbering, they were asked for it again. ARIN asked nothing concerning the DHCP pools, which by themselves qualified the address space." My understanding was that our consensus policy is that an ISP is expected to reveal customer information about assignments of /29 and larger. So, this brings to mind two questions: 1. Do current ARIN staff procedures have situations which place a mandatory requirement for an ISP to reveal (under NDA or otherwise) customers to whom less than a /29 of address spaces has been assigned? By "mandatory" I mean that ARIN staff will not accept an alternate form of demonstration that the /32 assignments are in use. The customer identities are required. 2. If ARIN staff procedures are in fact as described in #1, from which NRPM policies do those particular procedures derive? Thanks, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rcarpen at network1.net Thu Apr 26 16:43:41 2012 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 26 Apr 2012 16:43:41 -0400 (EDT) Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: Message-ID: I work with several ISPs, and to my knowledge, none of them have ever been asked to provide any more information than what is already in SWIP/WHOIS, which would mean only /29 and shorter. In fact, I don't think they have ever been asked anything at all. I just assumed that since the SWIP/WHOIS data was already there, it was being used. In many cases I have seen "/24 allocated as /32 static assignments to customers" be sufficient justification. -Randy ----- Original Message ----- > Hi folks, > > Paraphrasing a private message I received during a recent NANOG > discussion: > > "We have roughly 66 /32 customer assignments and a /24 for management > addresses (switches, waps, wireless backhauls, servers, etc). Also a > number of large assignments to DHCP pools. > > ARIN not only asked for the 66 customer names once, when the company > went back to ask for additional space after renumbering, they were > asked for it again. ARIN asked nothing concerning the DHCP pools, > which by themselves qualified the address space." > > > My understanding was that our consensus policy is that an ISP is > expected to reveal customer information about assignments of /29 and > larger. So, this brings to mind two questions: > > 1. Do current ARIN staff procedures have situations which place a > mandatory requirement for an ISP to reveal (under NDA or otherwise) > customers to whom less than a /29 of address spaces has been > assigned? > By "mandatory" I mean that ARIN staff will not accept an alternate > form of demonstration that the /32 assignments are in use. The > customer identities are required. > > 2. If ARIN staff procedures are in fact as described in #1, from > which > NRPM policies do those particular procedures derive? > > Thanks, > 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. > > From jeffrey.lyon at blacklotus.net Thu Apr 26 17:06:44 2012 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 26 Apr 2012 17:06:44 -0400 Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: References: Message-ID: On Thu, Apr 26, 2012 at 4:36 PM, William Herrin wrote: > Hi folks, > > Paraphrasing a private message I received during a recent NANOG discussion: > > "We have roughly 66 /32 customer assignments and a /24 for management > addresses (switches, waps, wireless backhauls, servers, etc). Also a > number of large assignments to DHCP pools. > > ARIN not only asked for the 66 customer names once, when the company > went back to ask for additional space after renumbering, they were > asked for it again. ARIN asked nothing concerning the DHCP pools, > which by themselves qualified the address space." > > > My understanding was that our consensus policy is that an ISP is > expected to reveal customer information about assignments of /29 and > larger. So, this brings to mind two questions: > > 1. Do current ARIN staff procedures have situations which place a > mandatory requirement for an ISP to reveal (under NDA or otherwise) > customers to whom less than a /29 of address spaces has been assigned? > By "mandatory" I mean that ARIN staff will not accept an alternate > form of demonstration that the /32 assignments are in use. The > customer identities are required. > > 2. If ARIN staff procedures are in fact as described in #1, from which > NRPM policies do those particular procedures derive? > > Thanks, > 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. Bill, When we made our last IPv4 request to go from /21 to /20 we were asked for the specific justification for each individual /32. I questioned this practice and was informed that the reason was we had a large percentage of IP space dedicated to internal infrastructure (~30% routers, switches, DDoS mitigation appliances, etc.) -- Jeffrey A. Lyon, CISSP President | (757) 304-0668 http://www.blacklotus.net Black Lotus Communications From jcurran at arin.net Thu Apr 26 17:19:07 2012 From: jcurran at arin.net (John Curran) Date: Thu, 26 Apr 2012 21:19:07 +0000 Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: References: Message-ID: <400C3AB3-2BF1-4468-A85B-5AB5F9D03F50@corp.arin.net> On Apr 26, 2012, at 1:36 PM, William Herrin wrote: > 1. Do current ARIN staff procedures have situations which place a > mandatory requirement for an ISP to reveal (under NDA or otherwise) > customers to whom less than a /29 of address spaces has been assigned? > By "mandatory" I mean that ARIN staff will not accept an alternate > form of demonstration that the /32 assignments are in use. The > customer identities are required. Bill - A party requesting space must show that the present space is in use. While this generally won't involve us asking for individual customers names, I can imagine circumstances where the ISP offered documentation doesn't suffice and we ask for more detailed data including customer names. > 2. If ARIN staff procedures are in fact as described in #1, from which > NRPM policies do those particular procedures derive? Verification of utilization information (as required by NRPM 4.2) is not constrained in the information that ARIN might request (or more often, what an ISP might offer) as evidence of utilization. We are generally flexible, but do on occasion ask for multiple sources of the similar data to compare and confirm veracity (this can catch folks who want to generate creative "utilization" evidence via perl scripts...) FYI, /John John Curran President and CEO ARIN From jlewis at lewis.org Thu Apr 26 16:56:41 2012 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 26 Apr 2012 16:56:41 -0400 (EDT) Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: References: Message-ID: On Thu, 26 Apr 2012, William Herrin wrote: > My understanding was that our consensus policy is that an ISP is > expected to reveal customer information about assignments of /29 and > larger. So, this brings to mind two questions: > > 1. Do current ARIN staff procedures have situations which place a > mandatory requirement for an ISP to reveal (under NDA or otherwise) > customers to whom less than a /29 of address spaces has been assigned? > By "mandatory" I mean that ARIN staff will not accept an alternate > form of demonstration that the /32 assignments are in use. The > customer identities are required. > > 2. If ARIN staff procedures are in fact as described in #1, from which > NRPM policies do those particular procedures derive? This is really a no-brainer. The requirement to SWIP or rwhois assignments down to /29 is a separate issue from the requirement to demonstrate efficient use of IP space. Also note the "including but not limited to" phrase below, which implies ARIN could ask you to document the usage of every single /32 if they felt it necessary. 4.2.3.7. Registration ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use. 4.2.3.7.1. Reassignment Information Each IPv4 assignment containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. If you could "hide" behind "these blocks are all /30 customer assignments, that's all you need to know", then a member could just lie to ARIN and say all (or >80% of) their space is in use, and request more Of course, you could also just make up a bunch of customers too...but that requires a bit more creativity than "you don't need to see the customer info for these /30s." ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From tim.gimmel at metronetinc.com Thu Apr 26 17:42:10 2012 From: tim.gimmel at metronetinc.com (Tim Gimmel) Date: Thu, 26 Apr 2012 16:42:10 -0500 Subject: [arin-ppml] Revealing /32 customers? Message-ID: That is not true! I just received an /21 allocation and in order to get the allocation I was required to send customer names for every address for a DHCP /25. I have asked repeatedly why, on cable DHCP groups, this necessary since is not required by ARIN policy. I advised the representative this needs to be make clear in ARIN policy so our company can put procedures in place to easily supply this data when asking for more resources. I guess this is why I comment. Regards, Tim Gimmel ============================================ Tim Gimmel V:812-456-4750 Senior Network Engineer?? M:270-454-7035 Metronet, Inc. tim.gimmel at metronetinc.com See. Explore. Hear What you've Been Missing! ============================================ -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Randy Carpenter Sent: Thursday, April 26, 2012 3:44 PM To: William Herrin Cc: ARIN PPML Subject: Re: [arin-ppml] Revealing /32 customers? I work with several ISPs, and to my knowledge, none of them have ever been asked to provide any more information than what is already in SWIP/WHOIS, which would mean only /29 and shorter. In fact, I don't think they have ever been asked anything at all. I just assumed that since the SWIP/WHOIS data was already there, it was being used. In many cases I have seen "/24 allocated as /32 static assignments to customers" be sufficient justification. -Randy ----- Original Message ----- > Hi folks, > > Paraphrasing a private message I received during a recent NANOG > discussion: > > "We have roughly 66 /32 customer assignments and a /24 for management > addresses (switches, waps, wireless backhauls, servers, etc). Also a > number of large assignments to DHCP pools. > > ARIN not only asked for the 66 customer names once, when the company > went back to ask for additional space after renumbering, they were > asked for it again. ARIN asked nothing concerning the DHCP pools, > which by themselves qualified the address space." > > > My understanding was that our consensus policy is that an ISP is > expected to reveal customer information about assignments of /29 and > larger. So, this brings to mind two questions: > > 1. Do current ARIN staff procedures have situations which place a > mandatory requirement for an ISP to reveal (under NDA or otherwise) > customers to whom less than a /29 of address spaces has been assigned? > By "mandatory" I mean that ARIN staff will not accept an alternate > form of demonstration that the /32 assignments are in use. The > customer identities are required. > > 2. If ARIN staff procedures are in fact as described in #1, from which > NRPM policies do those particular procedures derive? > > Thanks, > 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. > > _______________________________________________ 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 rcarpen at network1.net Thu Apr 26 17:48:46 2012 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 26 Apr 2012 17:48:46 -0400 (EDT) Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: Message-ID: <3213b494-c048-49a1-a3e3-3ad7f7e2adb5@zimbra.network1.net> I suppose they are becoming more strict in practice. If so, it would be nice to clarify in policy. -Randy ----- Original Message ----- > That is not true! > I just received an /21 allocation and in order to get the > allocation I was required to send customer names for every address > for a DHCP /25. I have asked repeatedly why, on cable DHCP > groups, this necessary since is not required by ARIN policy. I > advised the representative this needs to be make clear in ARIN > policy so our company can put procedures in place to easily supply > this data when asking for more resources. > I guess this is why I comment. > > Regards, > Tim Gimmel > > > ============================================ > Tim Gimmel V:812-456-4750 > Senior Network Engineer?? M:270-454-7035 > Metronet, Inc. tim.gimmel at metronetinc.com > See. Explore. Hear What you've Been Missing! > ============================================ > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of Randy Carpenter > Sent: Thursday, April 26, 2012 3:44 PM > To: William Herrin > Cc: ARIN PPML > Subject: Re: [arin-ppml] Revealing /32 customers? > > > I work with several ISPs, and to my knowledge, none of them have ever > been asked to provide any more information than what is already in > SWIP/WHOIS, which would mean only /29 and shorter. In fact, I don't > think they have ever been asked anything at all. I just assumed that > since the SWIP/WHOIS data was already there, it was being used. > > In many cases I have seen "/24 allocated as /32 static assignments to > customers" be sufficient justification. > > -Randy > > ----- Original Message ----- > > Hi folks, > > > > Paraphrasing a private message I received during a recent NANOG > > discussion: > > > > "We have roughly 66 /32 customer assignments and a /24 for > > management > > addresses (switches, waps, wireless backhauls, servers, etc). Also > > a > > number of large assignments to DHCP pools. > > > > ARIN not only asked for the 66 customer names once, when the > > company > > went back to ask for additional space after renumbering, they were > > asked for it again. ARIN asked nothing concerning the DHCP pools, > > which by themselves qualified the address space." > > > > > > My understanding was that our consensus policy is that an ISP is > > expected to reveal customer information about assignments of /29 > > and > > larger. So, this brings to mind two questions: > > > > 1. Do current ARIN staff procedures have situations which place a > > mandatory requirement for an ISP to reveal (under NDA or otherwise) > > customers to whom less than a /29 of address spaces has been > > assigned? > > By "mandatory" I mean that ARIN staff will not accept an alternate > > form of demonstration that the /32 assignments are in use. The > > customer identities are required. > > > > 2. If ARIN staff procedures are in fact as described in #1, from > > which > > NRPM policies do those particular procedures derive? > > > > Thanks, > > 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. > > > > > _______________________________________________ > 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 bill at herrin.us Thu Apr 26 18:02:16 2012 From: bill at herrin.us (William Herrin) Date: Thu, 26 Apr 2012 18:02:16 -0400 Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: <400C3AB3-2BF1-4468-A85B-5AB5F9D03F50@corp.arin.net> References: <400C3AB3-2BF1-4468-A85B-5AB5F9D03F50@corp.arin.net> Message-ID: On 4/26/12, John Curran wrote: > On Apr 26, 2012, at 1:36 PM, William Herrin wrote: >> 1. Do current ARIN staff procedures have situations which place a >> mandatory requirement for an ISP to reveal (under NDA or otherwise) >> customers to whom less than a /29 of address spaces has been assigned? >> By "mandatory" I mean that ARIN staff will not accept an alternate >> form of demonstration that the /32 assignments are in use. The >> customer identities are required. > > Bill - A party requesting space must show that the present space is > in use. While this generally won't involve us asking for individual > customers names, I can imagine circumstances where the ISP offered > documentation doesn't suffice and we ask for more detailed data > including customer names. Thanks John, Of course if I had my druthers, every IPv4 assignment would be a matter of public record, but I think you'll agree with me that this particular opinion bears no resemblance to the community's current consensus. I certainly think it reasonable to ARIN to suggest demonstrating utilization via a detailed list of customer assignments, especially if the allocation request is in any way suspicious. My concern is that if a list of such /32 customers becomes the *only* way to demonstrate the validity of /32 assignments that rather seems to tread on the policy text cutting off customer identification at /29. Surely there are other ways to check utilization! > do on occasion ask for multiple sources of the > similar data to compare and confirm veracity (this can catch folks who > want to generate creative "utilization" evidence via perl scripts...) I don't doubt it and I'm pleased to hear that ARIN is vigorously defending the address pool. I just want to make sure that if we've decided, as a matter of consensus based public policy, that assignments smaller than /29 are permitted to remain a private matter between ISP and customer that the staff procedures are not, in a roundabout way, contradicting or partially nullifying that policy. More to the point, if staff procedures are leaving any ISPs stranded with no choice but to reveal /32 customer identities, I'd like to see those procedures revised to better reflect the spirit of the /29 boundary called out multiple times in the NRPM, such as in 4.2.3.7.1. 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 Thu Apr 26 18:16:18 2012 From: jcurran at arin.net (John Curran) Date: Thu, 26 Apr 2012 22:16:18 +0000 Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: References: <400C3AB3-2BF1-4468-A85B-5AB5F9D03F50@corp.arin.net> Message-ID: On Apr 26, 2012, at 3:02 PM, William Herrin wrote: > > I don't doubt it and I'm pleased to hear that ARIN is vigorously > defending the address pool. I just want to make sure that if we've > decided, as a matter of consensus based public policy, that > assignments smaller than /29 are permitted to remain a private matter > between ISP and customer that the staff procedures are not, in a > roundabout way, contradicting or partially nullifying that policy. I do believe that the policy intent was to keep customer data private _with respect to public reassignment directories_, and not with respect to answering ARIN inquiries regarding utilization, but I could be mistaken. The policy origin of the language is in ARIN 2010-14 > More to the point, if staff procedures are leaving any ISPs stranded > with no choice but to reveal /32 customer identities, I'd like to see > those procedures revised to better reflect the spirit of the /29 > boundary called out multiple times in the NRPM, such as in 4.2.3.7.1. I believe the procedures we utilize are correct implementation of the policy (and policy intent with respect to 2010-14), but if you want specifically for ARIN to never seek information on customers with smaller than /29 reassignments, then I'd recommend making policy to that effect. Note to also amend NRPM 12, since that is definitely without constraints, regardless of the reading of ISP IPv4 policies. Thanks! /John John Curran President and CEO ARIN From jbates at brightok.net Thu Apr 26 18:12:02 2012 From: jbates at brightok.net (Jack Bates) Date: Thu, 26 Apr 2012 17:12:02 -0500 Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: <400C3AB3-2BF1-4468-A85B-5AB5F9D03F50@corp.arin.net> References: <400C3AB3-2BF1-4468-A85B-5AB5F9D03F50@corp.arin.net> Message-ID: <4F99C832.8040703@brightok.net> On 4/26/2012 4:19 PM, John Curran wrote: > Verification of utilization information (as required by NRPM 4.2) is > not constrained in the information that ARIN might request (or more > often, what an ISP might offer) as evidence of utilization. We are > generally flexible, but do on occasion ask for multiple sources of the > similar data to compare and confirm veracity (this can catch folks who > want to generate creative "utilization" evidence via perl scripts...) A person could lie about customer data about as easily as they could lie about arp tables with a perl script. If you want a true audit, why not do a meeting session and a quick verify within a router/switch/etc? Why cause a large amount of work on the part of honest requests (who probably don't have an IP -> Customer Name format readily available since it isn't mentioned in NRPM), especially when the requested information is for customers who don't even have to exist to receive an allocation? And is there ever a concern on a renumber when an ISP is registering an ASN (which I'm guessing required proof of multihoming) as well as the renumber request and has SWIPs for their PA space: CIDR - SWIP added /23 2004-09-29 /23 2007-07-02 DSL deployment and moron delaying issuing the SWIP (probably me) /23 2007-07-02 /23 2008-04-17 /23 2009-01-08 Renumber 2012 Granted, they may have asked for a /16 (which I thought was funny, but not completely unexpected out of people who don't know and haven't read the NRPM), ended up with a /21 (expected correction by ARIN), then after renumber had to go back and ask for the final /24 (luckily they consolidated 3 routed DHCP relay points for better utilization during renumber). My big concern is that ARIN is being more aggressive than PA allocation criteria. There is no indication that at some point ISPs need to collect this /32 information from our subtending ISPs. Granted, this makes it more attractive for someone to stay with PA space, but creating hardships for that reason doesn't seem appropriate (dual standard?). Jack From bill at herrin.us Thu Apr 26 18:39:18 2012 From: bill at herrin.us (William Herrin) Date: Thu, 26 Apr 2012 18:39:18 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement Message-ID: Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 1. Policy Proposal Name: Clarify /29 assignment identification requirement 2. Proposal Originator 1. name: William Herrin 2. email: bill at herrin.us 3. telephone: 703-534-2652 4. organization: self 3. Proposal Version: 1.0 4. Date: 4/26/2012 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: Where ARIN must evaluate a LIR's IPv4 address utilization in order to perform any duty, ARIN shall not compel the production of customer identities for any customer holding a total of less than 8 IPv4 addresses unless all reasonable alternatives for verifying utilization have been exhausted. 8. Rationale: Per http://lists.arin.net/pipermail/arin-ppml/2012-April/024523.html , ARIN believes the /29 border for identifying customers called out seven distinct times in the NRPM applies only to publication of such records. Author contends that the policy intention is and should be that the identity of such small consumers of IP addresses remain a private matter between the ISP and its customer. 9. Timetable for implementation: immediate END OF TEMPLATE -- 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 Thu Apr 26 18:45:18 2012 From: jcurran at arin.net (John Curran) Date: Thu, 26 Apr 2012 22:45:18 +0000 Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: <4F99C832.8040703@brightok.net> References: <400C3AB3-2BF1-4468-A85B-5AB5F9D03F50@corp.arin.net> <4F99C832.8040703@brightok.net> Message-ID: On Apr 26, 2012, at 3:12 PM, Jack Bates wrote: > A person could lie about customer data about as easily as they could lie about arp tables with a perl script. And they do indeed attempt that on occasion (which can be caught as well...) There's quite a bit of surprise when we ask ISPs for detailed contact information for some of their 'organizational customers' chosen at random that have received reassignments... but we do ask for that as well when it appears that the organizations in the reassignment list are predominantly fabricated. > If you want a true audit, why not do a meeting session and a quick verify within a router/switch/etc? I don't know if we've done an actual meeting session, but I know that we've done output dumps of various commands at the command line, verification from public looking glass locations, requested copies of equipment configuration, and even occasional read-only remote access. > Why cause a large amount of work on the part of honest requests (who probably don't have an IP -> Customer Name format readily available since it isn't mentioned in NRPM), especially when the requested information is for customers who don't even have to exist to receive an allocation? Actually, it's not a large amount of work since we rarely ask for it. Send us an 'interesting' request, and you will receive back a query for verification of some information and might be asked to confirm again in another matter. It is trivial to pregenerate a known format and known request, but much harder to handle (and forge) a request for something that you did not expect, particularly when it has to not only be complete but match your early generations. Trivial to dump and supply if you're authentic, but challenging otherwise. We decline those resource requests when the routine supporting followup information seems to be readily unavailable (i.e. w/o days to generate it) > My big concern is that ARIN is being more aggressive than PA allocation criteria. There is no indication that at some point ISPs need to collect this /32 information from our subtending ISPs. Granted, this makes it more attractive for someone to stay with PA space, but creating hardships for that reason doesn't seem appropriate (dual standard?). Either remove the utilization requirement, or state specifically what ARIN is to perform for verification (with the understanding that doing that will quickly result in toolkits to generate fraudulent materials in short order.) I believe the current system is not ideal and am certain it will be interesting during regional IPv4 runout, but I believe it does work. Changing the manner in which we verify need is something that can be done if the community feels that it is a policy priority at this time and there is consensus on how to change it. Thanks! /John John Curran President and CEO ARIN From lar at mwtcorp.net Thu Apr 26 18:56:55 2012 From: lar at mwtcorp.net (Larry Ash) Date: Thu, 26 Apr 2012 16:56:55 -0600 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On Thu, 26 Apr 2012 18:39:18 -0400 William Herrin wrote: > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 > > 1. Policy Proposal Name: Clarify /29 assignment identification requirement > 2. Proposal Originator > 1. name: William Herrin > 2. email: bill at herrin.us > 3. telephone: 703-534-2652 > 4. organization: self > 3. Proposal Version: 1.0 > 4. Date: 4/26/2012 > 5. Proposal type: new > 6. Policy term: permanent > 7. Policy statement: > > Where ARIN must evaluate a LIR's IPv4 address utilization in order to > perform any duty, ARIN shall not compel the production of customer > identities for any customer holding a total of less than 8 IPv4 > addresses unless all reasonable alternatives for verifying utilization > have been exhausted. > > 8. Rationale: > I tend to agree with the intent but not so much for privacy as for the simple fact that /32's tend to constantly be in flux. When I requested additional addressing it was obvious that until the SWIP showed very close to 80% the rest of the supporting documentation would not be reviewed. I was "advised" to SWIP all of my /30's and /32's. These have taken up most of the time I spend doing SWIP's since. It seems that they change daily. The smaller you are the greater the relative burden. Automation has an overhead that at a certain size is justified. Honesty becomes a major burden when the bureaucracy wants greater and greater detail. > Per http://lists.arin.net/pipermail/arin-ppml/2012-April/024523.html , > ARIN believes the /29 border for identifying customers called out > seven distinct times in the NRPM applies only to publication of such > records. Author contends that the policy intention is and should be > that the identity of such small consumers of IP addresses remain a > private matter between the ISP and its customer. > > 9. Timetable for implementation: immediate > > END OF TEMPLATE > > > -- > 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. Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From jbates at brightok.net Thu Apr 26 19:16:57 2012 From: jbates at brightok.net (Jack Bates) Date: Thu, 26 Apr 2012 18:16:57 -0500 Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: References: <400C3AB3-2BF1-4468-A85B-5AB5F9D03F50@corp.arin.net> <4F99C832.8040703@brightok.net> Message-ID: <4F99D769.8090706@brightok.net> On 4/26/2012 5:45 PM, John Curran wrote: > There's quite a bit of surprise when we ask ISPs for detailed contact > information for some of their 'organizational customers' chosen at > random that have received reassignments... but we do ask for that as > well when it appears that the organizations in the reassignment list > are predominantly fabricated. I never care about organizational customers. Given they generally have /29 or larger netblocks, they are forewarned concerning ARIN and get to enjoy long conference calls while we discuss how exactly they'll be using IP Address space. > I don't know if we've done an actual meeting session, but I know that > we've done output dumps of various commands at the command line, > verification from public looking glass locations, requested copies of > equipment configuration, and even occasional read-only remote access. This sort of thing makes better sense than asking for residential customer details; although I'd probably argue against uncensored views of configs. I don't believe in security through obscurity, but I also don't believe in letting people view snmp community names and encrypted passwords if it can be helped. > Actually, it's not a large amount of work since we rarely ask for it. > Send us an 'interesting' request, and you will receive back a query > for verification of some information and might be asked to confirm > again in another matter. It is trivial to pregenerate a known format > and known request, but much harder to handle (and forge) a request for > something that you did not expect, particularly when it has to not > only be complete but match your early generations. Trivial to dump and > supply if you're authentic, but challenging otherwise. We decline > those resource requests when the routine supporting followup > information seems to be readily unavailable (i.e. w/o days to generate > it) 66 customer details for /32 assignments is probably not readily available. I suspect it takes hours of hand typing or copy and pasting to generate that information. Depending on the size of the request, you may be asking for a database report instead of monkeys hand typing. That can take days to get requested by some companies. You rarely ask for it so it may be little work to ARIN, but it is a burden to the requester. >> My big concern is that ARIN is being more aggressive than PA allocation criteria. There is no indication that at some point ISPs need to collect this /32 information from our subtending ISPs. Granted, this makes it more attractive for someone to stay with PA space, but creating hardships for that reason doesn't seem appropriate (dual standard?). > Either remove the utilization requirement, or state specifically what ARIN > is to perform for verification (with the understanding that doing that will > quickly result in toolkits to generate fraudulent materials in short order.) > > I believe the current system is not ideal and am certain it will be > interesting during regional IPv4 runout, but I believe it does work. > Changing the manner in which we verify need is something that can be > done if the community feels that it is a policy priority at this time > and there is consensus on how to change it. > I think there are many things ARIN can do or request that doesn't include residential customer information or unfiltered access to a config. Some of them, such as meeting sessions would provide greater assurances of accurate details and should take less time to verify than reviewing a report of names (supposing ARIN actually reviews the report and doesn't just say, "They sent it, it looks okay, so accept it."). It also falls into the standard ISP/Corporate structure that is allowed for standard vendor interaction (Some places may let vendors run free, but some of us watch every little thing they do and restrict what they can see). Jack From jcurran at arin.net Thu Apr 26 19:26:52 2012 From: jcurran at arin.net (John Curran) Date: Thu, 26 Apr 2012 23:26:52 +0000 Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: <4F99D769.8090706@brightok.net> References: <400C3AB3-2BF1-4468-A85B-5AB5F9D03F50@corp.arin.net> <4F99C832.8040703@brightok.net> <4F99D769.8090706@brightok.net> Message-ID: On Apr 26, 2012, at 4:16 PM, Jack Bates wrote: > .. Some of them, such as meeting sessions would provide greater assurances of accurate details and should take less time to verify than reviewing a report of names Jack - We may easily be employing "meeting sessions" as a form of validation; I would need to check with the registration team. My point is only that ARIN needs to understand if requesting customer data is not one of the options to be used when validating utilization data. Presently, it may be asked for to support a request. If this is not the desired state, we need to know that, and whether there is a specific alternative or whether we're to accept the ISPs assertion as-is. Thanks! /John John Curran President and CEO ARIN From jbates at brightok.net Thu Apr 26 19:25:43 2012 From: jbates at brightok.net (Jack Bates) Date: Thu, 26 Apr 2012 18:25:43 -0500 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: <4F99D977.3060007@brightok.net> On 4/26/2012 5:39 PM, William Herrin wrote: > Where ARIN must evaluate a LIR's IPv4 address utilization in order to > perform any duty, ARIN shall not compel the production of customer > identities for any customer holding a total of less than 8 IPv4 > addresses unless all reasonable alternatives for verifying utilization > have been exhausted. > > I think it would be wiser to establish a structure of guidelines for auditing, personally. It appears ARIN also likes unfiltered configs or access to read unfiltered configs in routers, which provides much more detailed information concerning the network than the required justification (snmp communities, firewall rules, encrypted passwords). This would also cover the privacy issue of smaller customers. It would also be nice to place limits on if the data itself is kept by ARIN or purged. Does ARIN really need to keep private data indefinitely versus keeping that such data was received and signed off on by a representative? I'm not sure how long such data is currently kept. Perhaps John can say. Jack From jlewis at lewis.org Thu Apr 26 19:43:57 2012 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 26 Apr 2012 19:43:57 -0400 (EDT) Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On Thu, 26 Apr 2012, Larry Ash wrote: > I tend to agree with the intent but not so much for privacy as for the > simple fact that /32's tend to constantly be in flux. When I requested > additional addressing it was obvious that until the SWIP showed very > close to 80% the rest of the supporting documentation would not be > reviewed. I was "advised" to SWIP all of my /30's and /32's. These have > taken up most of the time I spend doing SWIP's since. It seems that they > change daily. The smaller you are the greater the relative burden. > Automation has an overhead that at a certain size is justified. > > Honesty becomes a major burden when the bureaucracy wants greater and greater > detail. I disagree. At any given instant in time, you should know how all your IP space is allocated. If you're preparing documentation for ARIN to tell them which customers reassignments you haven't SWIP'd are assigned to, you give them the data as of the time you're preparing the document. If your assignments change that quickly, you can include a note that "this report is correct as of ????-??-??, but some reassignments may have changed by the time you read it." The issue is that some members do a horrible job of keeping track of their IP usage[1], and with IPv4 runout basically here, "I don't think we have any more IPs left, can we have some more?" just doesn't cut it anymore. If you don't know where all of your IPs are, you have no business asking for more. If you do know where they are, telling ARIN shouldn't be a burden. [1] Years ago, I did some very short work with a web hosting provider (they had >/16 worth of various CIDRs). They had zero internal documentation of IP assignments other than router/switch configs. I don't know how they even functioned like that. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jcurran at arin.net Thu Apr 26 19:57:53 2012 From: jcurran at arin.net (John Curran) Date: Thu, 26 Apr 2012 23:57:53 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <4F99D977.3060007@brightok.net> References: <4F99D977.3060007@brightok.net> Message-ID: <4808F5A2-0D59-4F77-AA7B-007C1EC63E04@corp.arin.net> On Apr 26, 2012, at 4:25 PM, Jack Bates wrote: > I think it would be wiser to establish a structure of guidelines for auditing, personally. It appears ARIN also likes unfiltered configs or access to read unfiltered configs in routers, which provides much more detailed information concerning the network than the required justification (snmp communities, firewall rules, encrypted passwords). This would also cover the privacy issue of smaller customers. Jack - ARIN does not require unfiltered access to configs; feel free to redact snmp communities, encrypted passwords, secret filter rules, and similar data. > It would also be nice to place limits on if the data itself is kept by ARIN or purged. Does ARIN really need to keep private data indefinitely versus keeping that such data was received and signed off on by a representative? I'm not sure how long such data is currently kept. Perhaps John can say. We keep ticket data indefinitely (because it supports the accuracy of the registry) but have standard record retention policies for other data (e.g. emails with supporting data) In the ideal world, your request and a supporting note from staff of review of technical data would be kept for long-term integrity, and we would purge any other non-request data after 2 years. As it is, emails to hostmaster are associated with tickets (as they may be requests or supporting information) and are retained indefinitely as well. We've just established a fairly major records retention program, and need to figure out how to expand that to include request supporting data in a way that makes sense. For now, your tickets and hostmaster emails are retained, and everything else (e.g. email direct to me) is on a two-year retention. My preference would be to provide you visibility (eg. via ARIN online) into old supporting data, but we may have to set up a system which works well for new requests and manually go through the past records and remove any now unneeded supporting data. FYI, /John John Curran President and CEO ARIN From mysidia at gmail.com Thu Apr 26 20:34:00 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 26 Apr 2012 19:34:00 -0500 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <4F99D977.3060007@brightok.net> References: <4F99D977.3060007@brightok.net> Message-ID: On 4/26/12, Jack Bates wrote: > I think it would be wiser to establish a structure of guidelines for > auditing, personally. It appears ARIN also likes unfiltered configs or > access to read unfiltered configs in routers, which provides much more > detailed information concerning the network than the required > justification (snmp communities, firewall rules, encrypted passwords). [snip] This is not really a "number resource policy" but nevertheless, there should be internal rules about what is collected and how collected data is handled. I can see there are potentially huge network security risks with ARIN staff ever being provided access to read unfiltered router configurations that contain passwords and SNMP access details. Retaining unfiltered configs for any significant amount of time is definitely something ARIN should not do; if ARIN receives an unfilitered config, they should filter it immediately -- any submissions of potentially sensitive information should be accepted only in a strongly encrypted manner, and should be kept strongly encrypted at all times (e.g. never sent in an e-mail, and no portion ever stored unencrypted at rest). I am opposed to the proposal as written. It is not unreasonable that ARIN request documentation of IP address usage down to the /32 level, as of a specific date. The /29 cutoff pertains to the maintenace of CONTACT information in external databases that are publicly visible.. The internal records of WHO or what person/organization/equipment individual IPs are assigned to, and/or the documentation of justification, must always be maintained, and made available to ARIN when it will facilitate their auditing requirements. The record of assignment of an IP is different from CONTACT records. -- -JH From jbates at brightok.net Thu Apr 26 21:03:47 2012 From: jbates at brightok.net (Jack Bates) Date: Thu, 26 Apr 2012 20:03:47 -0500 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <4F99D977.3060007@brightok.net> Message-ID: <4F99F073.1030307@brightok.net> On 4/26/2012 7:34 PM, Jimmy Hess wrote: > The internal records of WHO or what person/organization/equipment > individual IPs are assigned to, and/or the documentation of > justification, must always be maintained, and made available to ARIN > when it will facilitate their auditing requirements. The record of > assignment of an IP is different from CONTACT records. Sure. I have no doubt that most ISPs record what a /32 assignment is assigned to. The problem, and the burden comes in the fact that the records kept for such things do not reflect what ARIN may ask for. Example: details of each piece of equipment that the ISP assigns an IP to. Some ISPs may have easily queried inventory systems. I suspect most small ISPs do not, and some large ones may not be able to easily query the information. Customer assignments may go across multiple databases or spreadsheets, depending on how the ISP setup. I've seen spreadsheets that assign an IP to an interface, then spreadsheets that assign an ATM PVC to a phone number, then a billing system that attaches the phone number to a customer name. In addition, there may be a separate database that contains a username/customer name/IP assignment information, but the IP information is just an added note. ie, it's easier referenced one direction than it it the other. Given a certain user, you can lookup what IP they use, but given an IP, more work is required to find the user; much less provide a report for ARIN. Jack From cgrundemann at gmail.com Thu Apr 26 21:13:59 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 26 Apr 2012 19:13:59 -0600 Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: References: <400C3AB3-2BF1-4468-A85B-5AB5F9D03F50@corp.arin.net> Message-ID: On Thu, Apr 26, 2012 at 16:16, John Curran wrote: > On Apr 26, 2012, at 3:02 PM, William Herrin wrote: >> >> I don't doubt it and I'm pleased to hear that ARIN is vigorously >> defending the address pool. I just want to make sure that if we've >> decided, as a matter of consensus based public policy, that >> assignments smaller than /29 are permitted to remain a private matter >> between ISP and customer that the staff procedures are not, in a >> roundabout way, contradicting or partially nullifying that policy. > > I do believe that the policy intent was to keep customer data private > _with respect to public reassignment directories_, and not with > respect to answering ARIN inquiries regarding utilization, but I > could be mistaken. ?The policy origin of the language is in ARIN > 2010-14 > >> More to the point, if staff procedures are leaving any ISPs stranded >> with no choice but to reveal /32 customer identities, I'd like to see >> those procedures revised to better reflect the spirit of the /29 >> boundary called out multiple times in the NRPM, such as in 4.2.3.7.1. > > I believe the procedures we utilize are correct implementation of > the policy (and policy intent with respect to 2010-14), but if you > want specifically for ARIN to never seek information on customers > with smaller than /29 reassignments, then I'd recommend making policy > to that effect. ?Note to also amend NRPM 12, since that is definitely > without constraints, regardless of the reading of ISP IPv4 policies. As the originator of Policy Proposal 109[1] which went on to become 2010-14 and now makes up the current text in section 4.2.3.7.[2], I can unequivocally state that the intention of that policy (and the corresponding IPv6 policy) was to place limitations on the public SWIP/WHOIS records only. In fact, all of the limiting language mentions SWIP directly if I am not mistaken. There was no intent to limit ARINs ability to conduct full audits, under NDA, when appropriate. Of course, this does not mean that there is no room for future policy changes in this area (and I'm happy to help sort any needed changes out), only that ARIN staff's current practices are fully inline with current policy as far as I can tell. Cheers, ~Chris [1] - http://lists.arin.net/pipermail/arin-ppml/2010-February/016528.html [2] - https://www.arin.net/policy/nrpm.html#four237 > > Thanks! > /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. -- @ChrisGrundemann http://chrisgrundemann.com From owen at delong.com Thu Apr 26 21:18:07 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 26 Apr 2012 18:18:07 -0700 Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: References: <400C3AB3-2BF1-4468-A85B-5AB5F9D03F50@corp.arin.net> Message-ID: On Apr 26, 2012, at 3:16 PM, John Curran wrote: > On Apr 26, 2012, at 3:02 PM, William Herrin wrote: >> >> I don't doubt it and I'm pleased to hear that ARIN is vigorously >> defending the address pool. I just want to make sure that if we've >> decided, as a matter of consensus based public policy, that >> assignments smaller than /29 are permitted to remain a private matter >> between ISP and customer that the staff procedures are not, in a >> roundabout way, contradicting or partially nullifying that policy. > > I do believe that the policy intent was to keep customer data private > _with respect to public reassignment directories_, and not with > respect to answering ARIN inquiries regarding utilization, but I > could be mistaken. The policy origin of the language is in ARIN > 2010-14 > Let's be clear... That intent is limited to allocations/assignments /29 or longer and residential customers ONLY. Others have no intent or expectation of privacy in NRPM. Owen From mysidia at gmail.com Thu Apr 26 21:44:26 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 26 Apr 2012 20:44:26 -0500 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <4F99F073.1030307@brightok.net> References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> Message-ID: On 4/26/12, Jack Bates wrote: [snip] > Sure. I have no doubt that most ISPs record what a /32 assignment is > assigned to. The problem, and the burden comes in the fact that the > records kept for such things do not reflect what ARIN may ask for. While ARIN's auditing and review practices are and internal procedure issue, and therefore out of scope of the PDP or the number resource policy, What I feel should happen is ARIN should actually publish guidance, and specific forms, stating what will routinely be requested in standard resource reviews and application for resources, information such that ISPs are appropriately prepared. Or "examples" of the documentation that ARIN will request. Guidance documentation should be maintained and updated before changes to ARIN's practices take effect. I can understand the ISP/applicant not having their existing usage information condensed into the form matching exactly what ARIN wants; if ARIN has not provided them the details they need to plan for resource reviews, if ARIN has recently changed what they required, or if the ISP's staff has had little experience with applying for additional resources. It would be like the government tax authority keeping information about the tax form you need to fill out, and what receipts you need to keep every year, until the day before taxes are due. -- -JH From cb.list6 at gmail.com Thu Apr 26 22:06:19 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 26 Apr 2012 19:06:19 -0700 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On Apr 26, 2012 3:39 PM, "William Herrin" wrote: > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 > > 1. Policy Proposal Name: Clarify /29 assignment identification requirement > 2. Proposal Originator > 1. name: William Herrin > 2. email: bill at herrin.us > 3. telephone: 703-534-2652 > 4. organization: self > 3. Proposal Version: 1.0 > 4. Date: 4/26/2012 > 5. Proposal type: new > 6. Policy term: permanent > 7. Policy statement: > > Where ARIN must evaluate a LIR's IPv4 address utilization in order to > perform any duty, ARIN shall not compel the production of customer > identities for any customer holding a total of less than 8 IPv4 > addresses unless all reasonable alternatives for verifying utilization > have been exhausted. > > 8. Rationale: > > Per http://lists.arin.net/pipermail/arin-ppml/2012-April/024523.html , > ARIN believes the /29 border for identifying customers called out > seven distinct times in the NRPM applies only to publication of such > records. Author contends that the policy intention is and should be > that the identity of such small consumers of IP addresses remain a > private matter between the ISP and its customer. > > 9. Timetable for implementation: immediate > > END OF TEMPLATE > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > +1 support In many cases, this data is so transient it has no audit value. Smartphones, for example, seldom have ip assignments that last longer than 12 hours and are so unsticky they are likely to never have the same ip twice Furthermore, folks who interface with arin && gear may only know a custimer via a customer id or phone number. The asociated personally identifiable information (pii ) of such a subscriber may be in a protected data warehouse that network folks dont have access too. In fact, this name to ip address correlation business process may only be in place for the purpose of lawful intercept under court issued warrant. I believe arin is generally doing the right thing today. But, clarifying this process is prudent. I am happy to provide gear configs and logs to arin for justification, but pii is sacred ground. Cb _______________________________________________ > 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 jbates at brightok.net Thu Apr 26 22:14:03 2012 From: jbates at brightok.net (Jack Bates) Date: Thu, 26 Apr 2012 21:14:03 -0500 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> Message-ID: <4F9A00EB.2090806@brightok.net> On 4/26/2012 8:44 PM, Jimmy Hess wrote: > > While ARIN's auditing and review practices are and internal procedure > issue, and therefore out of scope of the PDP or the number resource > policy, Only in the fact that it doesn't limit auditing. The NRPM does provide for auditing, so it could be clarified. > What I feel should happen is ARIN should actually publish guidance, > and specific forms, stating what will routinely be requested in > standard resource reviews and application for resources, information > such that ISPs are appropriately prepared. > Or "examples" of the documentation that ARIN will request. > I believe their fear here is that people will just write script kits to forge such information. I believe it would be better to strictly push for meeting sessions and direct viewing of information upon request in collaboration with the ISP when there is a question concerning the standard forms and the desire to verify. Benefits: 1. The ARIN representative is viewing the information and signing off on it. No actual data is being stored by ARIN. This allows the ISP to guide and restrict what is being viewed to a degree to safeguard against any unauthorized activity an ARIN representative might engage in. It also reduces the amount of private data ARIN does store. 2. Except for the smallest requests, it allows ARIN to be very random on what they want to view and by questioning the ISP, view a variety of datapoints for verification like dhcp pools, snooping pools, ppp sessions, dslam screens showing connected ports, data traffic loads/counters for a variety of interface types. In some cases, ISP might not be against showing live flow data at PE, which could be verified against data sent in real time from ARIN representative (see, this is a real router!). Or, because not everyone is a connectivity provider, I presume one could view a few commands on a server to see mass usage of address space for X reason (although I'd think most SSL/IP setups just generate a quick scan of those sites by ARIN). 3. Makes it much more difficult for someone to make a fraudulent request without creating what equates to a full ISP. Cons: 1. Representatives may spend more time in a meeting than they would analyzing "paper" which is submitted. 2. Representatives would need to understand ISP technologies to be versatile in what information to ask for. Jack From mysidia at gmail.com Thu Apr 26 23:07:52 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 26 Apr 2012 22:07:52 -0500 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On 4/26/12, Cameron Byrne wrote: > In many cases, this data is so transient it has no audit value. > Smartphones, for example, seldom have ip assignments that last longer than > 12 hours and are so unsticky they are likely to never have the same ip [snip] If you are an LIR, you don't assign an IP "for 12 hours" to a smart phone. You assign a range of IPs to the customer's DHCP-served LAN, or you assign a range of IPs to your own organization for providing DHCP-based access. Your documentation requirement is the range of IPs assigned to that customer for their LAN. If you are the end user, your documentation requirement is the DHCP LAN range identification in your rfc2050 Network Engineering Plan, and the number of devices (or number of customers served by that range). You need to document /32s, when the /32 is actually what's been re-assigned. Not when the /32 is a member of a dynamically assigned pool on your LAN, or when you have assigned a pool of IPs to a customer; you document the pool. > Furthermore, folks who interface with arin && gear may only know a custimer > via a customer id or phone number. The asociated personally identifiable > information (pii ) of such a subscriber may be in a protected data > warehouse that network folks dont have access too. The application for additional resources from ARIN is to be done by a person whom has the ability to gather the information required for the application. Some organizations may have implemented special security controls around PII that prevent network staff from routinely accessing it, but that is an internal issue -- if obtaining additional IP address space is a business requirement, the security controls will surely be adapted to meet the organization's business requirement. The network staff most certainly have some way of accessing the contact details of their customer's network manager, however, otherwise they would not be able to contact the customer about network-related issues such as abuse. Its really not a good reason for reducing the documentation requirements for obtaining IPv4 sources near runout -- -JH From tim.gimmel at metronetinc.com Thu Apr 26 23:30:10 2012 From: tim.gimmel at metronetinc.com (Tim Gimmel) Date: Thu, 26 Apr 2012 22:30:10 -0500 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <4F9A00EB.2090806@brightok.net> References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> Message-ID: -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jack Bates Sent: Thursday, April 26, 2012 9:14 PM To: Jimmy Hess Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Clarify /29 assignment identification requirement On 4/26/2012 8:44 PM, Jimmy Hess wrote: > > While ARIN's auditing and review practices are and internal procedure > issue, and therefore out of scope of the PDP or the number resource > policy, Only in the fact that it doesn't limit auditing. The NRPM does provide for auditing, so it could be clarified. > What I feel should happen is ARIN should actually publish guidance, > and specific forms, stating what will routinely be requested in > standard resource reviews and application for resources, information > such that ISPs are appropriately prepared. > Or "examples" of the documentation that ARIN will request. > I believe their fear here is that people will just write script kits to forge such information. Of course this is possible. It's also possible all the data could be fraudulent! But you cannot have all polices revolve around the few bad apples; they will show up. Polices should apply the most organizations universally. Now that we are in runout and can only receive 3 month supply of IP addresses, ISPs must now watch their IP usage at the most granular level as possible. So when it time to request more resources we want to be able to give the ARIN representatives exactly what they need to make an informed decision quickly. If it is not stated in policy what will be requested then delays will ensue as the ISP tries to figure out how to fulfill the request, i.e. write scripts to read DHCP pools, then then link with customer databases etc. This is very inefficient. Our experience is when we hit 80% we have to get moving quickly to request resources, because by the time we get past the allocation procedure, get all upstream providers to open prefixes, get our own systems opened for the new prefix we are down to our last /24. I am curious as the issue with tracking /32's, this seems like the easiest to track. Now I am referring to STATIC /32. DHCP pools are a different animal; systems must be put into place to read leases files and then pull customer information to match with each address. If ISP SWIP's per NPRM 4.2.3.7.3, and then asks for specifics for each individual customer in DHCP pools, this needs to be explicitly stated. Otherwise there will always be delays in processing resource requests as the ISP goes and fetches the information requested. It will never be ideal, but knowing what is expected is the best path to success. --Tim I believe it would be better to strictly push for meeting sessions and direct viewing of information upon request in collaboration with the ISP when there is a question concerning the standard forms and the desire to verify. Benefits: 1. The ARIN representative is viewing the information and signing off on it. No actual data is being stored by ARIN. This allows the ISP to guide and restrict what is being viewed to a degree to safeguard against any unauthorized activity an ARIN representative might engage in. It also reduces the amount of private data ARIN does store. 2. Except for the smallest requests, it allows ARIN to be very random on what they want to view and by questioning the ISP, view a variety of datapoints for verification like dhcp pools, snooping pools, ppp sessions, dslam screens showing connected ports, data traffic loads/counters for a variety of interface types. In some cases, ISP might not be against showing live flow data at PE, which could be verified against data sent in real time from ARIN representative (see, this is a real router!). Or, because not everyone is a connectivity provider, I presume one could view a few commands on a server to see mass usage of address space for X reason (although I'd think most SSL/IP setups just generate a quick scan of those sites by ARIN). 3. Makes it much more difficult for someone to make a fraudulent request without creating what equates to a full ISP. Cons: 1. Representatives may spend more time in a meeting than they would analyzing "paper" which is submitted. 2. Representatives would need to understand ISP technologies to be versatile in what information to ask for. Jack _______________________________________________ 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 mysidia at gmail.com Thu Apr 26 23:38:34 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 26 Apr 2012 22:38:34 -0500 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <4F9A00EB.2090806@brightok.net> References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> Message-ID: On 4/26/12, Jack Bates wrote: > Only in the fact that it doesn't limit auditing. The NRPM does provide > for auditing, so it could be clarified. What I mean is that the NRPM section 12 provides for "resource review" of any resource in the ARIN database at any time. That was added by 2007-14. The procedures to do these reviews, and the auditing of requests to ensure compliance with the NRPM each would fall under "ARIN general business practices and procedures". The proposal states "unless all reasonable alternatives for verifying utilization have been exhausted." In other words, "exhaust all reasonable alternatives before compelling the production of customer identities for any customer holding a total of less than 8 IPv4 addresses" "Do this first, before that"; The proposal is a procedure. > I believe their fear here is that people will just write script kits to > forge such information. ARIN can provide guidance without facilitating that. -- -JH From jcurran at arin.net Thu Apr 26 23:57:00 2012 From: jcurran at arin.net (John Curran) Date: Fri, 27 Apr 2012 03:57:00 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> Message-ID: <694FE9DA-2392-477C-8E1D-5709654FADBE@corp.arin.net> On Apr 26, 2012, at 8:30 PM, Tim Gimmel wrote: > > Now that we are in runout and can only receive 3 month supply of IP addresses, ISPs must now watch their IP usage at the most granular level as possible. So when it time to request more resources we want to be able to give the ARIN representatives exactly what they need to make an informed decision quickly. Tim - Just for clarity, there is are forms in ARIN Online and there are instructions online regarding what information you need to supply - The question is the "verification" phase of the request, where it is true that ARIN often asks for additional information to confirm the accuracy of the request. It turns out there there are folks who would like to receive IPv4 resources from the free pool despite having no need (or their actual unstated need is to quickly uniquely number several hundred virtual email servers on a provider-independent network block, send a lot of mail, and disappear...) ARIN presently does not provide a guidebook how what information we're going to ask for in validation, because it would inevitably be an equally valid roadmap for how to prepare forged materials for verification. We are quite aware that organizations need their additional resources promptly, and move very quickly as long as an organization is responsive to information requests. Now, if you wish to make it even more efficient, we can do away with verification (or make it completely programmatic) but that will have significant consequences in the ability to determine the accuracy of any requests. It may that working with smaller 90 day allocations make that a valid tradeoff, but we're going to need ample community discussion if to move in that direction. Thanks for your thoughts on this! /John John Curran President and CEO ARIN From narten at us.ibm.com Fri Apr 27 00:53:02 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 27 Apr 2012 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201204270453.q3R4r2Qa020230@rotala.raleigh.ibm.com> Total of messages in the last 7 days. script run at: Fri Apr 27 00:53:02 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ --------+------+--------+----------+------------------------ From narten at us.ibm.com Fri Apr 27 07:16:26 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 27 Apr 2012 07:16:26 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201204271116.q3RBGQOb021667@rotala.raleigh.ibm.com> Total of 33 messages in the last 7 days. script run at: Fri Apr 27 07:16:26 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 18.18% | 6 | 16.73% | 40419 | jcurran at arin.net 15.15% | 5 | 13.95% | 33720 | jbates at brightok.net 12.12% | 4 | 11.25% | 27187 | mysidia at gmail.com 9.09% | 3 | 8.48% | 20497 | bill at herrin.us 6.06% | 2 | 7.55% | 18247 | tim.gimmel at metronetinc.com 6.06% | 2 | 6.48% | 15663 | rcarpen at network1.net 6.06% | 2 | 5.77% | 13949 | jlewis at lewis.org 3.03% | 1 | 5.00% | 12092 | cb.list6 at gmail.com 3.03% | 1 | 3.87% | 9362 | jack.stevens at centurylink.com 3.03% | 1 | 3.43% | 8281 | cgrundemann at gmail.com 3.03% | 1 | 3.39% | 8195 | yi.chu at sprint.com 3.03% | 1 | 3.18% | 7677 | jeffrey.lyon at blacklotus.net 3.03% | 1 | 3.01% | 7271 | lar at mwtcorp.net 3.03% | 1 | 2.98% | 7194 | john.kuhn at ontario.ca 3.03% | 1 | 2.64% | 6369 | owen at delong.com 3.03% | 1 | 2.29% | 5538 | markk at arin.net --------+------+--------+----------+------------------------ 100.00% | 33 |100.00% | 241661 | Total From bill at herrin.us Fri Apr 27 08:04:46 2012 From: bill at herrin.us (William Herrin) Date: Fri, 27 Apr 2012 08:04:46 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> Message-ID: On 4/26/12, Jimmy Hess wrote: > In other words, "exhaust all reasonable alternatives before > compelling the production of customer identities for any customer > holding a total of less than 8 IPv4 addresses" > > "Do this first, before that"; The proposal is a procedure. Jimmy, That criticism can be levied against just about any would-be policy which states an exception. "This" unless "that" in policy means evaluate "that" before you consider "this" in the derived procedures. "Blocks smaller than /29 may be documented in bulk as 'small customer assignments'" is at least as clearly policy as what's actually in the NRPM now. But that would leave ARIN with hands tied when a purported ISP says, "This /12 consists only of /32 customer assignments." Can you offer a suggestion for proposal language -with- the exception that doesn't fall afoul of what you see as straying into procedure? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From david at airbits.com Fri Apr 27 10:27:38 2012 From: david at airbits.com (David Krumme) Date: Fri, 27 Apr 2012 08:27:38 -0600 Subject: [arin-ppml] /32 assignment identification requirement In-Reply-To: References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> Message-ID: I recently applied for a /21 and was asked for a list of subnets and customers because all of our assignments are static /32. I had no problem with providing it based on our existing records and it didn't surprise me or bother me that they asked for it. Anyone big enough to need a /21 is going to have records in online form. I wouldn't even have been surprised if they had followed up and spot-checked a few individual customers. ARIN's audit procedures should not be spelled out in public and should vary and not be predictable. That's how audits work. I would object to the idea of anyone outside my organization being given any kind of online access to my routers or computers. There are all kinds of issues to worry about there. -David From jbates at brightok.net Fri Apr 27 10:48:20 2012 From: jbates at brightok.net (Jack Bates) Date: Fri, 27 Apr 2012 09:48:20 -0500 Subject: [arin-ppml] /32 assignment identification requirement In-Reply-To: References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> Message-ID: <4F9AB1B4.3010505@brightok.net> On 4/27/2012 9:27 AM, David Krumme wrote: > I would object to the idea of anyone outside my organization being given > any kind of online access to my routers or computers. There are all kinds > of issues to worry about there. What kind of issues are there for ARIN to watch a readonly meeting session as you type commands or display certain information? It's only slightly removed from them standing behind you at your computer. Jack From hannigan at gmail.com Fri Apr 27 10:48:55 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 27 Apr 2012 07:48:55 -0700 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: I support this proposal. On Thursday, April 26, 2012, William Herrin wrote: > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 > > 1. Policy Proposal Name: Clarify /29 assignment identification > requirement > 2. Proposal Originator > 1. name: William Herrin > 2. email: bill at herrin.us > 3. telephone: 703-534-2652 > 4. organization: self > 3. Proposal Version: 1.0 > 4. Date: 4/26/2012 > 5. Proposal type: new > 6. Policy term: permanent > 7. Policy statement: > > Where ARIN must evaluate a LIR's IPv4 address utilization in order to > perform any duty, ARIN shall not compel the production of customer > identities for any customer holding a total of less than 8 IPv4 > addresses unless all reasonable alternatives for verifying utilization > have been exhausted. > > 8. Rationale: > > Per http://lists.arin.net/pipermail/arin-ppml/2012-April/024523.html , > ARIN believes the /29 border for identifying customers called out > seven distinct times in the NRPM applies only to publication of such > records. Author contends that the policy intention is and should be > that the identity of such small consumers of IP addresses remain a > private matter between the ISP and its customer. > > 9. Timetable for implementation: immediate > > END OF TEMPLATE > > > -- > 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. > -- Sent via a mobile device -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Fri Apr 27 11:41:15 2012 From: info at arin.net (ARIN) Date: Fri, 27 Apr 2012 11:41:15 -0400 Subject: [arin-ppml] ARIN-prop-166 Clarify /29 assignment identification requirement In-Reply-To: <4F9AB819.6040609@arin.net> References: <4F9AB819.6040609@arin.net> Message-ID: <4F9ABE1B.1010403@arin.net> ARIN-prop-166 Clarify /29 assignment identification requirement ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found 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 Mailing list subscription information can be found at:https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-166 Clarify /29 assignment identification requirement Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 1. Policy Proposal Name: Clarify /29 assignment identification requirement 2. Proposal Originator 1. name: William Herrin 2. email:bill at herrin.us 3. telephone: 703-534-2652 4. organization: self 3. Proposal Version: 1.0 4. Date: 4/26/2012 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: Where ARIN must evaluate a LIR's IPv4 address utilization in order to perform any duty, ARIN shall not compel the production of customer identities for any customer holding a total of less than 8 IPv4 addresses unless all reasonable alternatives for verifying utilization have been exhausted. 8. Rationale: Perhttp://lists.arin.net/pipermail/arin-ppml/2012-April/024523.html , ARIN believes the /29 border for identifying customers called out seven distinct times in the NRPM applies only to publication of such records. Author contends that the policy intention is and should be that the identity of such small consumers of IP addresses remain a private matter between the ISP and its customer. 9. Timetable for implementation: immediate END OF TEMPLATE -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at airbits.com Fri Apr 27 12:05:01 2012 From: david at airbits.com (David Krumme) Date: Fri, 27 Apr 2012 10:05:01 -0600 Subject: [arin-ppml] /32 assignment identification requirement In-Reply-To: <4F9AB1B4.3010505@brightok.net> References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> <4F9AB1B4.3010505@brightok.net> Message-ID: <7e1aca2b98a526c785408a69059cd873.squirrel@webmail.airbits.com> > On 4/27/2012 9:27 AM, David Krumme wrote: >> I would object to the idea of anyone outside my organization being given >> any kind of online access to my routers or computers. There are all >> kinds >> of issues to worry about there. > > What kind of issues are there for ARIN to watch a readonly meeting > session as you type commands or display certain information? It's only > slightly removed from them standing behind you at your computer. > > > Jack Well, let's see... First, I don't know what a "readonly meeting session" is and I wouldn't know how to set one up. I guess that's problem #1. Mostly the other concerns are security related. I have a fiduciary relationship with my customers and one of the primary ways of maintaining security is by not disclosing information that need not be disclosed. Disclosing secret information across the Internet to someone I don't know just seems wrong. A person physically present in my office is a lot less of a security risk, and the secret information need never leave the office. Also, the person can only take away what they can see and remember. -David From jbates at brightok.net Fri Apr 27 12:26:04 2012 From: jbates at brightok.net (Jack Bates) Date: Fri, 27 Apr 2012 11:26:04 -0500 Subject: [arin-ppml] /32 assignment identification requirement In-Reply-To: <7e1aca2b98a526c785408a69059cd873.squirrel@webmail.airbits.com> References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> <4F9AB1B4.3010505@brightok.net> <7e1aca2b98a526c785408a69059cd873.squirrel@webmail.airbits.com> Message-ID: <4F9AC89C.5040503@brightok.net> On 4/27/2012 11:05 AM, David Krumme wrote: > First, I don't know what a "readonly meeting session" is and I wouldn't > know how to set one up. I guess that's problem #1. Similar to what router vendors request. You join a session (usually a java app loaded from a webpage) and share out your ssh window so that they can watch what you are doing. Generally a vendor can type themselves, but it's possible to have it readonly (vendor just watches). While it is possible that the rep could screen capture, the information you'd show would be less than what they normally ask to be emailed to them. As it currently stands, a lot of information is just sent via email and stored in the ticketing system. Jack From lee at dilkie.com Fri Apr 27 12:32:22 2012 From: lee at dilkie.com (Lee Dilkie) Date: Fri, 27 Apr 2012 12:32:22 -0400 Subject: [arin-ppml] /32 assignment identification requirement In-Reply-To: <4F9AC89C.5040503@brightok.net> References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> <4F9AB1B4.3010505@brightok.net> <7e1aca2b98a526c785408a69059cd873.squirrel@webmail.airbits.com> <4F9AC89C.5040503@brightok.net> Message-ID: <4F9ACA16.2090705@dilkie.com> On 4/27/2012 12:26 PM, Jack Bates wrote: > On 4/27/2012 11:05 AM, David Krumme wrote: >> First, I don't know what a "readonly meeting session" is and I wouldn't >> know how to set one up. I guess that's problem #1. > > Similar to what router vendors request. You join a session (usually a > java app loaded from a webpage) and share out your ssh window so that > they can watch what you are doing. Generally a vendor can type > themselves, but it's possible to have it readonly (vendor just watches). > > While it is possible that the rep could screen capture, the > information you'd show would be less than what they normally ask to be > emailed to them. As it currently stands, a lot of information is just > sent via email and stored in the ticketing system. > > > Jack > _______________________________________________ > It seems to me, and I am not a lawyer, that even requesting third party customer information, much less storing it is just a ticking time bomb... waiting for the day ARIN gets either hacked or a disgruntled/wikileaks employee posts the information either publically or sells it. -lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgrundemann at gmail.com Fri Apr 27 13:09:12 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 27 Apr 2012 11:09:12 -0600 Subject: [arin-ppml] /32 assignment identification requirement In-Reply-To: <4F9ACA16.2090705@dilkie.com> References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> <4F9AB1B4.3010505@brightok.net> <7e1aca2b98a526c785408a69059cd873.squirrel@webmail.airbits.com> <4F9AC89C.5040503@brightok.net> <4F9ACA16.2090705@dilkie.com> Message-ID: On Fri, Apr 27, 2012 at 10:32, Lee Dilkie wrote: > It seems to me, and I am not a lawyer, that even requesting third party > customer information, much less storing it is just a ticking time bomb... > waiting for the day ARIN gets either hacked or a disgruntled/wikileaks > employee posts the information either publically or sells it. Of course, that could happen at the ISP as well... > -lee > > > _______________________________________________ > 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. -- @ChrisGrundemann http://chrisgrundemann.com From jrhett at netconsonance.com Fri Apr 27 13:45:19 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Fri, 27 Apr 2012 10:45:19 -0700 Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: References: <400C3AB3-2BF1-4468-A85B-5AB5F9D03F50@corp.arin.net> <4F99C832.8040703@brightok.net> Message-ID: On Apr 26, 2012, at 3:45 PM, John Curran wrote: > Changing the manner in which we verify need is something that can be > done if the community feels that it is a policy priority at this time > and there is consensus on how to change it. FWIW, I have been through "easy" and "hard" justifications with ARIN before, and I have found your process to work very well. Even when I had to acquire information we didn't have readily available for proof, the logic for the validation seemed clear to me. I see no need for change at this time. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbates at brightok.net Fri Apr 27 14:00:21 2012 From: jbates at brightok.net (Jack Bates) Date: Fri, 27 Apr 2012 13:00:21 -0500 Subject: [arin-ppml] /32 assignment identification requirement In-Reply-To: References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> <4F9AB1B4.3010505@brightok.net> <7e1aca2b98a526c785408a69059cd873.squirrel@webmail.airbits.com> <4F9AC89C.5040503@brightok.net> <4F9ACA16.2090705@dilkie.com> Message-ID: <4F9ADEB5.3050305@brightok.net> On 4/27/2012 12:09 PM, Chris Grundemann wrote: > On Fri, Apr 27, 2012 at 10:32, Lee Dilkie wrote: > >> It seems to me, and I am not a lawyer, that even requesting third party >> customer information, much less storing it is just a ticking time bomb... >> waiting for the day ARIN gets either hacked or a disgruntled/wikileaks >> employee posts the information either publically or sells it. > Of course, that could happen at the ISP as well... > Of course. Like any secret, the more copies of the secret there are, the more likely it will spread or become public knowledge. It also becomes more problematic when you have a single location that contains a lot of secrets. It makes it more of a target for abuse. Jack From jrhett at netconsonance.com Fri Apr 27 14:08:13 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Fri, 27 Apr 2012 11:08:13 -0700 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On Apr 26, 2012, at 3:39 PM, William Herrin wrote: > 1. Policy Proposal Name: Clarify /29 assignment identification requirement I do not support this proposal. In fact this issue would bring me very actively out against it. In particular because it will effectively remove all validation of mobile phone, cable and dsl operators. It may be tricky to say "exactly this customer has this IP" but it is fairly trivial to show ARIN that you have a pool of customers this size who are configured within the given dynamic pool. ARIN has been very flexible with accepting the information in the form it was the easiest for us to provide it at the time. Re "fairly trivial": unless you have given each customer IP information and then forgotten it, and you have no idea who has what or how they got it? which is simply isn't a valid way to operate. You have this information. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffrey.lyon at blacklotus.net Fri Apr 27 14:21:43 2012 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 27 Apr 2012 14:21:43 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On Fri, Apr 27, 2012 at 2:08 PM, Jo Rhett wrote: > On Apr 26, 2012, at 3:39 PM, William Herrin wrote: > > ? 1. Policy Proposal Name: Clarify /29 assignment identification requirement > > > I do not support this proposal. In fact this issue would bring me very > actively out against it. In particular because it will effectively remove > all validation of mobile phone, cable and dsl operators. > > It may be tricky to say "exactly this customer has this IP" but it is fairly > trivial to show ARIN that you have a pool of customers this size who are > configured within the given dynamic pool. ARIN has been very flexible with > accepting the information in the form it was the easiest for us to provide > it at the time. > > Re "fairly trivial": unless you have given each customer IP information and > then forgotten it, and you have no idea who has what or how they got it? > which is simply isn't a valid way to operate. You have this information. > > -- > Jo Rhett > Net Consonance :?net philanthropy to improve open source and internet > projects. > > > > > _______________________________________________ > 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. My position is that any assignment of < /29 to a private individual should be classifiable as "Private assignment" without further discussion, so long as these assignments do not make up a majority of the justification. -- Jeffrey A. Lyon, CISSP President | (757) 304-0668 http://www.blacklotus.net Black Lotus Communications From cgrundemann at gmail.com Fri Apr 27 14:24:34 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 27 Apr 2012 12:24:34 -0600 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On Fri, Apr 27, 2012 at 12:21, Jeffrey Lyon wrote: > My position is that any assignment of < /29 to a private individual > should be classifiable as "Private assignment" without further > discussion, so long as these assignments do not make up a majority of > the justification. To be clear: You would accept a justification in which 49% of the address space simply said "private assignments?" ~Chris > -- > Jeffrey A. Lyon, CISSP > President | (757) 304-0668 > http://www.blacklotus.net > Black Lotus Communications > _______________________________________________ > 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. -- @ChrisGrundemann http://chrisgrundemann.com From jeffrey.lyon at blacklotus.net Fri Apr 27 14:26:04 2012 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 27 Apr 2012 14:26:04 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On Fri, Apr 27, 2012 at 2:24 PM, Chris Grundemann wrote: > On Fri, Apr 27, 2012 at 12:21, Jeffrey Lyon wrote: > >> My position is that any assignment of < /29 to a private individual >> should be classifiable as "Private assignment" without further >> discussion, so long as these assignments do not make up a majority of >> the justification. > > To be clear: You would accept a justification in which 49% of the > address space simply said "private assignments?" > > ~Chris > >> -- >> Jeffrey A. Lyon, CISSP >> President | (757) 304-0668 >> http://www.blacklotus.net >> Black Lotus Communications >> _______________________________________________ >> 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. > > > > -- > @ChrisGrundemann > http://chrisgrundemann.com Correct. -- Jeffrey A. Lyon, CISSP President | (757) 304-0668 http://www.blacklotus.net Black Lotus Communications From jrhett at netconsonance.com Fri Apr 27 14:32:18 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Fri, 27 Apr 2012 11:32:18 -0700 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: <09CFE0D8-8CD5-424D-80AE-FECF658F71E8@netconsonance.com> > On Fri, Apr 27, 2012 at 2:24 PM, Chris Grundemann wrote: >> To be clear: You would accept a justification in which 49% of the >> address space simply said "private assignments?" On Apr 27, 2012, at 11:26 AM, Jeffrey Lyon wrote: > > Correct. Hm. I see an instantaneous grab of all remaining IPv4 space if Jeffrey has his way. I personally feel that this would be irresponsible for ARIN to do, and that I've had to document individual assignments before and it simply wasn't that difficult to do. Any operating business knows who has assignments in which address pools. It's not hard to provide. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlewis at lewis.org Fri Apr 27 14:33:27 2012 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 27 Apr 2012 14:33:27 -0400 (EDT) Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On Fri, 27 Apr 2012, Jeffrey Lyon wrote: > My position is that any assignment of < /29 to a private individual > should be classifiable as "Private assignment" without further > discussion, so long as these assignments do not make up a majority of > the justification. So, it's ok to use /29 "private individual" assignments to pad your IP utilization up beyond 80% in order to qualify for more space now, before ARIN is out? No. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From lee at dilkie.com Fri Apr 27 14:40:09 2012 From: lee at dilkie.com (Lee Dilkie) Date: Fri, 27 Apr 2012 14:40:09 -0400 Subject: [arin-ppml] /32 assignment identification requirement In-Reply-To: <4F9ADEB5.3050305@brightok.net> References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> <4F9AB1B4.3010505@brightok.net> <7e1aca2b98a526c785408a69059cd873.squirrel@webmail.airbits.com> <4F9AC89C.5040503@brightok.net> <4F9ACA16.2090705@dilkie.com> <4F9ADEB5.3050305@brightok.net> Message-ID: <4F9AE809.9060606@dilkie.com> On 4/27/2012 2:00 PM, Jack Bates wrote: > On 4/27/2012 12:09 PM, Chris Grundemann wrote: >> On Fri, Apr 27, 2012 at 10:32, Lee Dilkie wrote: >> >>> It seems to me, and I am not a lawyer, that even requesting third party >>> customer information, much less storing it is just a ticking time >>> bomb... >>> waiting for the day ARIN gets either hacked or a disgruntled/wikileaks >>> employee posts the information either publically or sells it. >> Of course, that could happen at the ISP as well... >> > Of course. Like any secret, the more copies of the secret there are, > the more likely it will spread or become public knowledge. It also > becomes more problematic when you have a single location that contains > a lot of secrets. It makes it more of a target for abuse. > > > Jack My point was more along the lines of "this is third party information". It's one thing for an ISP's customer list to be compromised. At least in a lawsuit a customer cannot claim that the ISP had no right to store the data. But I worry that for ARIN the argument would come down to that, does ARIN have more liability because it would have to make a non-obvious argument as to why it needed to possess such data.. just me being a worry-wart I guess. -lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrhett at netconsonance.com Fri Apr 27 14:56:50 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Fri, 27 Apr 2012 11:56:50 -0700 Subject: [arin-ppml] /32 assignment identification requirement In-Reply-To: <4F9AE809.9060606@dilkie.com> References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> <4F9AB1B4.3010505@brightok.net> <7e1aca2b98a526c785408a69059cd873.squirrel@webmail.airbits.com> <4F9AC89C.5040503@brightok.net> <4F9ACA16.2090705@dilkie.com> <4F9ADEB5.3050305@brightok.net> <4F9AE809.9060606@dilkie.com> Message-ID: <2D6DA88A-33A5-40A4-BE1D-150CE58B30A5@netconsonance.com> On Apr 27, 2012, at 11:40 AM, Lee Dilkie wrote: > My point was more along the lines of "this is third party information". It's one thing for an ISP's customer list to be compromised. At least in a lawsuit a customer cannot claim that the ISP had no right to store the data. But I worry that for ARIN the argument would come down to that, does ARIN have more liability because it would have to make a non-obvious argument as to why it needed to possess such data.. I had half a dozen contracts of this nature handy, and every single one of them says that the company may provide my information to their partners as necessary to provide my service. This is also well covered by existing law. This is a very old wheel. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Apr 27 15:48:00 2012 From: jcurran at arin.net (John Curran) Date: Fri, 27 Apr 2012 19:48:00 +0000 Subject: [arin-ppml] /32 assignment identification requirement In-Reply-To: <4F9AE809.9060606@dilkie.com> References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> <4F9AB1B4.3010505@brightok.net> <7e1aca2b98a526c785408a69059cd873.squirrel@webmail.airbits.com> <4F9AC89C.5040503@brightok.net> <4F9ACA16.2090705@dilkie.com> <4F9ADEB5.3050305@brightok.net> <4F9AE809.9060606@dilkie.com> Message-ID: <39827D59-DB1E-4E60-893A-FA43FE7BBEF9@corp.arin.net> On Apr 27, 2012, at 11:40 AM, Lee Dilkie wrote: > My point was more along the lines of "this is third party information". It's one thing for an ISP's customer list to be compromised. At least in a lawsuit a customer cannot claim that the ISP had no right to store the data. But I worry that for ARIN the argument would come down to that, does ARIN have more liability because it would have to make a non-obvious argument as to why it needed to possess such data.. > > just me being a worry-wart I guess. Lee - It is a reasonable concern and worth discussing. This is existing practice (requesting fairly detailed technical and business information as needed for request verification) and while we are in the midst of review our retention practices for such data, the current practice is considered a reasonable risk in light of our needs for faithful execution of policy. i.e. It would be impossible (in many cases) to verify a request with any degree of certainty with such data, and the duty to protect the comes with the policy administration duties unless the policy requirements are trivial. The argument is fairly straightforward to explain even if non-obvious from a lay perspective. Thanks for raising this! /John John Curran President and CEO ARIN From jcurran at arin.net Fri Apr 27 16:02:26 2012 From: jcurran at arin.net (John Curran) Date: Fri, 27 Apr 2012 20:02:26 +0000 Subject: [arin-ppml] /32 assignment identification requirement In-Reply-To: <39827D59-DB1E-4E60-893A-FA43FE7BBEF9@corp.arin.net> References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> <4F9AB1B4.3010505@brightok.net> <7e1aca2b98a526c785408a69059cd873.squirrel@webmail.airbits.com> <4F9AC89C.5040503@brightok.net> <4F9ACA16.2090705@dilkie.com> <4F9ADEB5.3050305@brightok.net> <4F9AE809.9060606@dilkie.com> <39827D59-DB1E-4E60-893A-FA43FE7BBEF9@corp.arin.net> Message-ID: On Apr 27, 2012, at 12:48 PM, John Curran wrote: > i.e. It would be impossible (in many cases) to verify a request with any degree of certainty with such data, ... "withOUT such data" (apologies for typos while mobile) /John John Curran President and CEO ARIN From mysidia at gmail.com Fri Apr 27 19:43:52 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 27 Apr 2012 18:43:52 -0500 Subject: [arin-ppml] /32 assignment identification requirement In-Reply-To: References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> Message-ID: On 4/27/12, David Krumme wrote: [snip] > ARIN's audit procedures should not be spelled out in public and should > vary and not be predictable. That's how audits work. It is not necessary for ARIN to explain or maintain fixed audit procedures in order to provide guidance. They should provide details about what level of documentation resource holders are recommended to have available for their inspection. For example "Be able to identify the name, address, contact details, and show a signed contract" of the customer to which each address assignment is made." "Be prepared to have an ARIN staff member visit your site to count number of devices, or visually inspect your routers and review the configuration with you, to verify the network engineering." That in no way reveals exactly what will actually be requested. -- -JH From mysidia at gmail.com Fri Apr 27 20:02:30 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 27 Apr 2012 19:02:30 -0500 Subject: [arin-ppml] /32 assignment identification requirement In-Reply-To: <4F9AE809.9060606@dilkie.com> References: <4F99D977.3060007@brightok.net> <4F99F073.1030307@brightok.net> <4F9A00EB.2090806@brightok.net> <4F9AB1B4.3010505@brightok.net> <7e1aca2b98a526c785408a69059cd873.squirrel@webmail.airbits.com> <4F9AC89C.5040503@brightok.net> <4F9ACA16.2090705@dilkie.com> <4F9ADEB5.3050305@brightok.net> <4F9AE809.9060606@dilkie.com> Message-ID: On 4/27/12, Lee Dilkie wrote: > My point was more along the lines of "this is third party information". > It's one thing for an ISP's customer list to be compromised. At least in > a lawsuit a customer cannot claim that the ISP had no right to store the > data. But I worry that for ARIN the argument would come down to that, [snip] That would be a point on which I would expect ARIN's counsel to have provided input, when ARIN developed whatever its internal audit procedures and any security practices. Most likely with a priority for ensuring all reasonable actions are taken to prevent compromise, so that any compromise is not a result of negligence by ARIN. I would expect that if it were deemed an issue, steps would be taken to mitigate the risk. Organizations take responsible measures to protect highly sensitive information all the time. Do you have experience that gives you reason to question ARIN's security practices? -- -JH From hannigan at gmail.com Fri Apr 27 21:17:57 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 27 Apr 2012 18:17:57 -0700 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: Yes. On Friday, April 27, 2012, Chris Grundemann wrote: > On Fri, Apr 27, 2012 at 12:21, Jeffrey Lyon > > wrote: > > > My position is that any assignment of < /29 to a private individual > > should be classifiable as "Private assignment" without further > > discussion, so long as these assignments do not make up a majority of > > the justification. > > To be clear: You would accept a justification in which 49% of the > address space simply said "private assignments?" > > ~Chris > > > -- > > Jeffrey A. Lyon, CISSP > > President | (757) 304-0668 > > http://www.blacklotus.net > > Black Lotus Communications > > _______________________________________________ > > 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. > > > > -- > @ChrisGrundemann > http://chrisgrundemann.com > _______________________________________________ > 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. > -- Sent via a mobile device -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Fri Apr 27 23:44:18 2012 From: bill at herrin.us (William Herrin) Date: Fri, 27 Apr 2012 23:44:18 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On 4/27/12, Jo Rhett wrote: > I do not support this proposal. In fact this issue would bring me very > actively out against it. In particular because it will effectively remove > all validation of mobile phone, cable and dsl operators. Jo, Have you considered the double-standard in place here? Where you specify a DHCP pool for always-on DSL users who may well hold a particular address for months, ARIN does not consider itself at liberty to inquire into the customers' identities and is able "validate" the use regardless. Yet if you explicitly assign them /32's... Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jlewis at lewis.org Sat Apr 28 01:12:22 2012 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 28 Apr 2012 01:12:22 -0400 (EDT) Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On Fri, 27 Apr 2012, William Herrin wrote: > Have you considered the double-standard in place here? > > Where you specify a DHCP pool for always-on DSL users who may well > hold a particular address for months, ARIN does not consider itself at > liberty to inquire into the customers' identities and is able > "validate" the use regardless. Yet if you explicitly assign them > /32's... I don't see it as a double-standard. If, by whatever process, you've manually assigned an IP to a customer, you will have a record of this, mapping that IP to the customer (with very few exceptions, most, if not all, of which I would call idiocy). If the IP assignment is via some automated process (DHCP, IPCP, etc.) then you likely have a pool of IPs for automated assignment, and regardless of how long those automated assignments last, I wouldn't expect you to have records (other than logs) mapping the assignment to a customer. In this case, you report the IP pool as X IPs for Y number of Z-type customers. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bill at herrin.us Sat Apr 28 07:21:33 2012 From: bill at herrin.us (William Herrin) Date: Sat, 28 Apr 2012 07:21:33 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On 4/28/12, Jon Lewis wrote: > On Fri, 27 Apr 2012, William Herrin wrote: >> Have you considered the double-standard in place here? > > I don't see it as a double-standard. If, by whatever process, you've > manually assigned an IP to a customer, you will have a record of > this, mapping that IP to the customer (with very few exceptions, most, if > not all, of which I would call idiocy). If the IP assignment is via some > automated process (DHCP, IPCP, etc.) then you likely have a pool of IPs > for automated assignment, and regardless of how long those automated > assignments last, I wouldn't expect you to have records (other than logs) > mapping the assignment to a customer. In this case, you report the IP > pool as X IPs for Y number of Z-type customers. Jon, Your always-on customers are always consuming an IP address. You know which ones are connected to which DHCP pools and you keep a record of which one attaches to which address so that you can deal with network abuse reports. Right? Why should you have the privilege of keeping those customer identities secret from ARIN when someone using a the more direct method of assigning a specific /32 to a customer does not? After all, when we talk "dynamic pools" we're usually not talking about dialups any more where a given customer will tie up an address for only a few hours a month. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From david at airbits.com Sat Apr 28 07:10:43 2012 From: david at airbits.com (David Krumme) Date: Sat, 28 Apr 2012 05:10:43 -0600 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: <9cd41a55282333090c19dbda1eb98166.squirrel@webmail.airbits.com> > If the IP assignment is via some > automated process (DHCP, IPCP, etc.) then you likely have a pool of IPs > for automated assignment, and regardless of how long those automated > assignments last, I wouldn't expect you to have records (other than logs) > mapping the assignment to a customer. I believe that CALEA requires us to be able to map IP to/from customer at any time upon request. So we are supposed to have such records. -David From lee at dilkie.com Sat Apr 28 08:01:36 2012 From: lee at dilkie.com (Lee Dilkie) Date: Sat, 28 Apr 2012 08:01:36 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <9cd41a55282333090c19dbda1eb98166.squirrel@webmail.airbits.com> References: <9cd41a55282333090c19dbda1eb98166.squirrel@webmail.airbits.com> Message-ID: <4F9BDC20.7000804@dilkie.com> On 4/28/2012 7:10 AM, David Krumme wrote: >> If the IP assignment is via some >> automated process (DHCP, IPCP, etc.) then you likely have a pool of IPs >> for automated assignment, and regardless of how long those automated >> assignments last, I wouldn't expect you to have records (other than logs) >> mapping the assignment to a customer. > I believe that CALEA requires us to be able to map IP to/from customer at > any time upon request. So we are supposed to have such records. > > -David > A bit of a US-centric view, don't you think? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlewis at lewis.org Sat Apr 28 09:32:55 2012 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 28 Apr 2012 09:32:55 -0400 (EDT) Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On Sat, 28 Apr 2012, William Herrin wrote: > Your always-on customers are always consuming an IP address. You know > which ones are connected to which DHCP pools and you keep a record of > which one attaches to which address so that you can deal with network > abuse reports. Right? > > Why should you have the privilege of keeping those customer identities > secret from ARIN when someone using a the more direct method of > assigning a specific /32 to a customer does not? Because in one case your staff has assigned an IP to a customer. In the other, an IP was automatically assigned to a customer, and it might stick with them for a few seconds to a few months. You have no idea how long, so your people make no record of the assignment. For abuse tracking, you would look at your network gear and/or its logs (RADIUS logs, etc.) to map an IP to customer. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bill at herrin.us Sat Apr 28 09:45:25 2012 From: bill at herrin.us (William Herrin) Date: Sat, 28 Apr 2012 09:45:25 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On 4/28/12, Jon Lewis wrote: > On Sat, 28 Apr 2012, William Herrin wrote: >> Your always-on customers are always consuming an IP address. You know >> which ones are connected to which DHCP pools and you keep a record of >> which one attaches to which address so that you can deal with network >> abuse reports. Right? >> >> Why should you have the privilege of keeping those customer identities >> secret from ARIN when someone using a the more direct method of >> assigning a specific /32 to a customer does not? > > Because in one case your staff has assigned an IP to a customer. In the > other, an IP was automatically assigned to a customer, and it might stick > with them for a few seconds to a few months. You have no idea how long, > so your people make no record of the assignment. For abuse tracking, you > would look at your network gear and/or its logs (RADIUS logs, etc.) to map > an IP to customer. When a hosting company assigns addresses to a newly provisioned VPS its every bit as automatic. And every bit as ephemeral: the customer may cancel in hours, days or years just as your DSL customer will hold an address (not necessarily that particular one) for the same period of time. Yet they're supposed to report that customer's identity in support of their address request while your DSL customer skates by anonymously? And is your DSL pool at all sticky, waiting a little while for the same MAC to present again before releasing the address? Double standard my friend. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From david at airbits.com Sat Apr 28 10:18:27 2012 From: david at airbits.com (David Krumme) Date: Sat, 28 Apr 2012 08:18:27 -0600 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <4F9BDC20.7000804@dilkie.com> References: <9cd41a55282333090c19dbda1eb98166.squirrel@webmail.airbits.com> <4F9BDC20.7000804@dilkie.com> Message-ID: <7a441723d730fba2cc49b1d390f94408.squirrel@webmail.airbits.com> > > > On 4/28/2012 7:10 AM, David Krumme wrote: >> I believe that CALEA requires us to be able to map IP to/from customer >> at >> any time upon request. So we are supposed to have such records. >> >> -David >> > > A bit of a US-centric view, don't you think? > > Oh, yeah, it would only affect ARIN's US customers. From jlewis at lewis.org Sat Apr 28 10:24:50 2012 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 28 Apr 2012 10:24:50 -0400 (EDT) Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On Sat, 28 Apr 2012, William Herrin wrote: > When a hosting company assigns addresses to a newly provisioned VPS > its every bit as automatic. And every bit as ephemeral: the customer > may cancel in hours, days or years just as your DSL customer will hold > an address (not necessarily that particular one) for the same period > of time. Yet they're supposed to report that customer's identity in > support of their address request while your DSL customer skates by > anonymously? That's true. I haven't had to deal with ARIN on a space request since we launched our cloud offering. But again, with cloud, we have pools of IPs, and as customers create/destroy virtual machines (which they do via a web portal or API), IPs are automatically assigned / returned to the pool. For cloud, I'd start out with "we've assigned these /24s to the cloud. We have X number of live customers, Y number of VMs on average, with Z number of VMs at peak." We actually have some customers who will spin up dozens of VMs for an hour, then destroy them all. Obviously, each VM needs at least one IP, and we have to have IP pools big enough to accomodate customer load. If I was applying for more space today, and ARIN demanded a mapping of IP->customer for our cloud IP pools, I could give it to them with some simple SQL statements. That data would be stale before it got to ARIN, and I'd include a note as such...and mention the above mentioned behavior of certain customers frequently creating large numbers of short-lived VMs, as justification for why there are many more IPs assigned to cloud than in use at the particular instant the report was generated. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jcurran at arin.net Sat Apr 28 14:34:33 2012 From: jcurran at arin.net (John Curran) Date: Sat, 28 Apr 2012 18:34:33 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On Apr 28, 2012, at 7:21 AM, William Herrin wrote: > Your always-on customers are always consuming an IP address. You know > which ones are connected to which DHCP pools and you keep a record of > which one attaches to which address so that you can deal with network > abuse reports. Right? > > Why should you have the privilege of keeping those customer identities > secret from ARIN when someone using a the more direct method of > assigning a specific /32 to a customer does not? > > After all, when we talk "dynamic pools" we're usually not talking > about dialups any more where a given customer will tie up an address > for only a few hours a month. Bill - Please do not assume that ARIN will not request information regarding actual customers assigned to dynamic IP pools; we do ask for this level of detail if necessary for verification (i.e. while we are generally satisfied by growth in customer counts, spot checking of those counts also occurs.) The same standard applies in either case: if you do not have an established record of growth and/or have unusual change in growth rate and/or show signs associated with common fraudulent requests, you will get asked for additional details. FYI, /John John Curran President and CEO ARIN From bill at herrin.us Sat Apr 28 15:50:20 2012 From: bill at herrin.us (William Herrin) Date: Sat, 28 Apr 2012 15:50:20 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On 4/28/12, John Curran wrote: > Please do not assume that ARIN will not request information regarding > actual customers assigned to dynamic IP pools; we do ask for this level > of detail if necessary for verification (i.e. while we are generally > satisfied by growth in customer counts, spot checking of those counts > also occurs.) > > The same standard applies in either case: if you do not have an established > record of growth and/or have unusual change in growth rate and/or show > signs associated with common fraudulent requests, you will get asked for > additional details. Hi John, Of the four folks across this conversation who've levied complaints about ARIN asking for customer identities for /32 users, none have expressed that ARIN inquired into customer identities for their dynamic pools and one expressly stated that ARIN didn't ask about the much larger dynamic pools at all. Four does not make a statistical sample but it does suggest a pattern. That having been said, you raise an issue I'd like to put to the floor: Per your statement above, ARIN considers itself at liberty to inquire into the personally identifiable information (PII) of the smallest and most ephemeral consumers of addresses among the ISP's customers during an ISP's application for addresses. Is that correct? Folks, is that what we want? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Sat Apr 28 16:13:30 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 28 Apr 2012 15:13:30 -0500 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On 4/28/12, William Herrin wrote: Well, I will say, that /32 dedicated user address assignments merit more scrutiny. Dynamic address pools are different, because no IP address is permanently assigned. The question then is not "is this customer actually using the resource"; but, are there enough (also identifiable) customers served by the pool, with a growth rate to justify a pool of that size. With single /32 dedicated assignments, there is a great danger that the ISP allocated the address to a customer, and out of laziness -- after that customer terminates service, the ISP neglects to take the manual actions required release the IP resource -- causing that to be wasted. Perhaps because it is more convenient to just allocate a new IP, and only cleanup when forced to do so, because the ARIN free pool has exhausted. > about ARIN asking for customer identities for /32 users, none have > expressed that ARIN inquired into customer identities for their > dynamic pools and one expressly stated that ARIN didn't ask about the > much larger dynamic pools at all. Four does not make a statistical > sample but it does suggest a pattern. The pattern it suggests is only that 4 or so organizations receiving information requests for ARIN regarding /32 assignments have raised issue with it. We have no way of knowing what caused their applications to raise suspicions of ARIN. We have no way of knowing if they are dismayed by the information request, because they want to attempt to squeeze more IPs out of ARIN than policy says they should be allocated. Or possibly they want more IPs out of ARIN, and see the requirement to properly document usage of /32s (still part of the public IP address resources) as a hinderance. I would expect ARIN to perform the necessary spot checking, if the rate of increase in usage/requirement of dynamically assigned pools is suspect. -- -JH From cb.list6 at gmail.com Sat Apr 28 16:38:04 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sat, 28 Apr 2012 13:38:04 -0700 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On Sat, Apr 28, 2012 at 12:50 PM, William Herrin wrote: > On 4/28/12, John Curran wrote: >> ?Please do not assume that ARIN will not request information regarding >> ?actual customers assigned to dynamic IP pools; we do ask for this level >> ?of detail if necessary for verification (i.e. while we are generally >> ?satisfied by growth in customer counts, spot checking of those counts >> ?also occurs.) >> >> ?The same standard applies in either case: if you do not have an established >> ?record of growth and/or have unusual change in growth rate and/or show >> ?signs associated with common fraudulent requests, you will get asked for >> ?additional ?details. > > Hi John, > > Of the four folks across this conversation who've levied complaints > about ARIN asking for customer identities for /32 users, none have > expressed that ARIN inquired into customer identities for their > dynamic pools and one expressly stated that ARIN didn't ask about the > much larger dynamic pools at all. Four does not make a statistical > sample but it does suggest a pattern. > > That having been said, you raise an issue I'd like to put to the floor: > > Per your statement above, ARIN considers itself at liberty to inquire > into the personally identifiable information (PII) of the smallest and > most ephemeral consumers of addresses among the ISP's customers during > an ISP's application for addresses. Is that correct? > > Folks, is that what we want? > No, i do not want that. Furthermore, i do not want ARIN storing this data about my customers indefinitely in their systems with no policy to ever purge the data. As it stands, if i understand it correctly, ARIN may demand and store the name and address of every person in the ARIN region who has an internet connection of any sort (cable, DSL, wireless, FTTH, e-reader ...) Frankly, this revelation is so shocking and unnerving i don't even feel comfortable discussing it on an open list. Audit is one thing. Storing PII on every broadband consumer in the ARIN region is quite another. CB > 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. From jcurran at arin.net Sat Apr 28 17:07:08 2012 From: jcurran at arin.net (John Curran) Date: Sat, 28 Apr 2012 21:07:08 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: <0743E1C1-C227-4B1F-B728-468F46D052AB@arin.net> On Apr 28, 2012, at 3:50 PM, William Herrin wrote: > > Of the four folks across this conversation who've levied complaints > about ARIN asking for customer identities for /32 users, none have > expressed that ARIN inquired into customer identities for their > dynamic pools and one expressly stated that ARIN didn't ask about the > much larger dynamic pools at all. Four does not make a statistical > sample but it does suggest a pattern. Indeed, it is an outline of a pleasant pattern that such information isn't generally needed nor requested. > ... > Per your statement above, ARIN considers itself at liberty to inquire > into the personally identifiable information (PII) of the smallest and > most ephemeral consumers of addresses among the ISP's customers during > an ISP's application for addresses. Is that correct? Interesting phrasing, but could be literally correct (even if taken to extreme...) I would have said it as thus: "In the absence of specific guidance from the community, ARIN will request sufficient supporting details as necessary to verify a request." > Folks, is that what we want? A most excellent question, and one which the community should definitely discuss. I'd ask that we set aside (temporarily) the question of retention of such detail, as it is apparent that ARIN retaining of such detail past an approved request should not be necessary (but we'll need to do some work to make sure this is the case.) Thanks, /John John Curran President and CEO ARIN From lar at mwtcorp.net Sat Apr 28 20:33:40 2012 From: lar at mwtcorp.net (Larry Ash) Date: Sat, 28 Apr 2012 18:33:40 -0600 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <0743E1C1-C227-4B1F-B728-468F46D052AB@arin.net> References: <0743E1C1-C227-4B1F-B728-468F46D052AB@arin.net> Message-ID: On Sat, 28 Apr 2012 21:07:08 +0000 John Curran wrote: > On Apr 28, 2012, at 3:50 PM, William Herrin wrote: >> >> Of the four folks across this conversation who've levied complaints >> about ARIN asking for customer identities for /32 users, none have >> expressed that ARIN inquired into customer identities for their >> dynamic pools and one expressly stated that ARIN didn't ask about the >> much larger dynamic pools at all. Four does not make a statistical >> sample but it does suggest a pattern. > > Indeed, it is an outline of a pleasant pattern that such information > isn't generally needed nor requested. > John, my case is an interesting one to note. I know why the reviewer was alerted. Some years earlier when I converted from PA to PI space I promised to renumber out of PA space withing 6 months. I did as requested but I didn't know until I made that request Qwest never withdrew the assignment. So, when the reviewer saw my request it looked like I had never made good on my original agreement. To this day my nameservers still get reverse requests on those IP's. I don't know if they every re-used any of that space but I'd guess not. The request itself was interesting because it wasn't as a result of normal growth. I had two small ISP customers that had PA from another provider and a third that had 1200 customers behind a NAT with a /29 of IP on the front end. He had some problems with law enforcement as he couldn't provide CALEA information when requested. I know he was honest in his description because I provide phone service to many of his customers and can see his ip's both RFC 1918 and public. My request was to allow the two to return their PA to the old provider and to try and get the third out of a bind. My actual utilization at the time was probably 78 - 79%, SWIP probably showed the low 70's. I expected some discussions and maybe some further justification. When it was clear that the process was going to take quite some time to come to a resolution we had to tell the customers we couldn't help them and drop it. Another thing to note. When requested, there is very limited information we can share. Any customer that is internet only, we can discuss it. Any customer that we provide phone service to you'll have to talk to our telco lawyer. The FCC has some very convoluted rules for phone companies about customer information under the name of CPNI. Mostly it has do do with call detail records but it's not always clear on related information. Any information that could potentially identify a phone customer and his voice traffic and/or equipment is problematic. The fines can be a mega-buck per violation. We don't go there. We don't read the rules and try and figure out if it applies or not. We just don't go there unless the request comes with a court order. >> ... >> Per your statement above, ARIN considers itself at liberty to inquire >> into the personally identifiable information (PII) of the smallest and >> most ephemeral consumers of addresses among the ISP's customers during >> an ISP's application for addresses. Is that correct? > > Interesting phrasing, but could be literally correct (even if taken > to extreme...) I would have said it as thus: > > "In the absence of specific guidance from the community, ARIN will > request sufficient supporting details as necessary to verify a request." > >> Folks, is that what we want? > > A most excellent question, and one which the community should > definitely discuss. I'd ask that we set aside (temporarily) > the question of retention of such detail, as it is apparent > that ARIN retaining of such detail past an approved request > should not be necessary (but we'll need to do some work to make > sure this is the case.) I have found it interesting. If I wanted to inflate the numbers /32's wouldn't be where I'd do it. However I'll bet I know where I could get thousands of names, addresses ,phone numbers, and GIS info so they were in similar neighborhoods etc. As always where there is a will there is a way. The methods have to be clear enough that we can be prepared to provide the information that you need but understand there are other forces in play so ARIN may need to be flexible. > > Thanks, > /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. Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From rbf+arin-ppml at panix.com Sun Apr 29 14:32:25 2012 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Sun, 29 Apr 2012 13:32:25 -0500 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: <20120429183225.GA8188@panix.com> On Sat, Apr 28, 2012 at 06:34:33PM +0000, John Curran wrote: > > Bill - > > Please do not assume that ARIN will not request information regarding > actual customers assigned to dynamic IP pools; we do ask for this level > of detail if necessary for verification (i.e. while we are generally > satisfied by growth in customer counts, spot checking of those counts > also occurs.) > > The same standard applies in either case: if you do not have an established > record of growth and/or have unusual change in growth rate and/or show signs > associated with common fraudulent requests, you will get asked for additional > details. > > FYI, > /John One thing that has been asserted a number of times in this thread is that ARIN has increased the level of scrutiny on requests during the time leading up to, and/or shortly after, IANA runout. (Presumably the trigger for any such increased scrutiny being the anticipated decrease availability of addresses, but my question is independent of the motivation.) Can you comment on whether or not this is the case. That is, in the time leading up to IANA runout, or shortly after that, did ARIN start scrutinizing provided documentation in more detail, or did ARIN start asking for more detail? (I'm talking about a general case decision to increase scrutiny in the time frame in question. I'm sure ARIN refines and has been refining its procedures over time as it learns what does and does not work, and I'm sure individual requests get a customized level of scrutiny as they are evaluated ... that would distinct from what I'm asking about.) Assume for the purposes of this question that the change to a three month allocation period and the officer attestation policy do not constitute increased scrutiny. -- Brett From scottleibrand at gmail.com Sun Apr 29 20:25:26 2012 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sun, 29 Apr 2012 17:25:26 -0700 Subject: [arin-ppml] Closing the reassignments to multihomed downstream customers loophole Message-ID: In the Policy Experience report at ARIN XXIX in Vancouver ( https://www.arin.net/participate/meetings/reports/ARIN_XXIX/PPT/tuesday/nobile_policy_experience.pptxor https://www.arin.net/participate/meetings/reports/ARIN_XXIX/PDF/tuesday/nobile_policy_experience.pdf), Leslie identified a: Potential loophole where customers can game the system: > > - Set up two OrgIDs > - Get an ASN for each > - Issue every customer a /24 and claim the two companies they control > are the upstream providers for each customer > > Basically an org who wants to sell a /24 as part of a service plan can do > so, and still be in compliance with policy, even though their customer has > no ASN or router and is not really multihomed Her report also suggested a fix, which was discussed during the Q&A. Based on that discussion, I modified the suggested language and came up with the following: In NRPM 4.2.3.6 (https://www.arin.net/policy/nrpm.html#four236): Insert "Downstream customer must have or qualify for their own ASN, and the customer (or both ISPs) must intend to originate a BGP route announcement for the /24 to their BGP neighbors." prior to "Customers may receive a /24 from only one of their upstream providers under this policy without providing additional justification." Change the following sentence to read "ISPs may demonstrate they have made an assignment to a downstream customer under this policy by supplying ARIN with the information they collected from the customer, as described above, and by identifying the AS number(s) that will be originating the /24. The idea is to require all ISP customers' making use of this policy to qualify for (but not necessarily receive) an ASN, and to require that they (or their ISPs, in rare cases) originate and announce the /24 into BGP. I think that would be sufficient to close the loophole without preventing legitimate non-BGP customers from getting a /24 for their ISPs to announce. I heard several people say at the microphone in Vancouver that this was a real problem they'd like to see addressed. Do you agree? Do you think this language addresses it? Do you see any possible unintended side effects? Is there anything you'd like to see changed about this language? If anyone thinks this would be a useful change, I'll be happy to submit it as a policy proposal. Alternately, if anyone else is interested in the issue and would like to be the policy proposal's originator, I could help as one of the AC shepherds instead. Any other thoughts, questions, or concerns? Thanks, Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbates at brightok.net Mon Apr 30 10:14:17 2012 From: jbates at brightok.net (Jack Bates) Date: Mon, 30 Apr 2012 09:14:17 -0500 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <0743E1C1-C227-4B1F-B728-468F46D052AB@arin.net> Message-ID: <4F9E9E39.40501@brightok.net> On 4/28/2012 7:33 PM, Larry Ash wrote: > Another thing to note. When requested, there is very limited > information we > can share. Any customer that is internet only, we can discuss it. Any > customer > that we provide phone service to you'll have to talk to our telco > lawyer. The > FCC has some very convoluted rules for phone companies about customer > information > under the name of CPNI. Mostly it has do do with call detail records > but it's > not always clear on related information. Any information that could > potentially > identify a phone customer and his voice traffic and/or equipment is > problematic. > The fines can be a mega-buck per violation. We don't go there. We > don't read the rules > and try and figure out if it applies or not. We just don't go there > unless the > request comes with a court order. This was my big concern, and I did warn (after the fact) the telco that didn't talk to their lawyer before sending the information to ARIN (probably didn't get an NDA, either). They were most likely audited for asking for some obscene CIDR block initially, but that probably isn't unusual out of people switching from PA to PI. In their ignorance, they ask for someone big and cool and ARIN corrects them in the followup for what they justify. However, as an ISP that serve's ISPs, I've never been requested to go to my ISP customers and ask them for this information. Some of them would laugh in my face. I wonder if this doesn't create an extra hardship between PI and PA justifications, and if that is something that is desired. Also, are we just picking on the little guy, while some of the largest networks (as mentioned elsewhere) are leaving huge blocks of networks SWIP'd after they've been released and possibly asking for more space? The smaller ISPs are more likely to have a 4-30% static assignment ratio compared to the larger ISPs, which seems to indicate they are more likely to get PII detail audits. Only ARIN can confirm what size of aggregate allocated space tends to generate this kind of detail, though. Jack From jcurran at arin.net Mon Apr 30 11:02:43 2012 From: jcurran at arin.net (John Curran) Date: Mon, 30 Apr 2012 15:02:43 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <4F9E9E39.40501@brightok.net> References: <0743E1C1-C227-4B1F-B728-468F46D052AB@arin.net> <4F9E9E39.40501@brightok.net> Message-ID: <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> On Apr 30, 2012, at 10:14 AM, Jack Bates wrote: > This was my big concern, and I did warn (after the fact) the telco that didn't talk to their lawyer before sending the information to ARIN (probably didn't get an NDA, either). They were most likely audited for asking for some obscene CIDR block initially, but that probably isn't unusual out of people switching from PA to PI. In their ignorance, they ask for someone big and cool and ARIN corrects them in the followup for what they justify. > > However, as an ISP that serve's ISPs, I've never been requested to go to my ISP customers and ask them for this information. Some of them would laugh in my face. I wonder if this doesn't create an extra hardship between PI and PA justifications, and if that is something that is desired. > > Also, are we just picking on the little guy, while some of the largest networks (as mentioned elsewhere) are leaving huge blocks of networks SWIP'd after they've been released and possibly asking for more space? The smaller ISPs are more likely to have a 4-30% static assignment ratio compared to the larger ISPs, which seems to indicate they are more likely to get PII detail audits. Only ARIN can confirm what size of aggregate allocated space tends to generate this kind of detail, though. Jack - If a significant amount of your utilization is based on discrete customer assignments (and we have no record of your previous utilization rates, as is common for an organization coming directly to ARIN for the first time), you are likely to be asked followup questions to verify that some of the individual customer assignments were done for actual customers. Also, if you're not actually an ISP serving customers, but instead a nice facade which has been created and carefully developed over several months for the sole purpose of getting a PI-allocation IPv4 address block out of ARIN, and now asserting a significant amount of utilization is based on unnamed customer assignments, you are also likely to be asked followup questions to verify the some of the individual customer assignments. (Note - If you do get an ARIN allocation for your "ISP", you're on your way to then having lots more imaginary firms rotating in and our as customers in the process getting your real business done, e.g. innovative marketing efforts, and by 'disconnecting those bad customers' repeatedly you've probably got a year or two until folks realize that you & your customers are one and the same...) While ARIN is concerned about IP address management, there are some interesting side effects of allowing ISP allocations to parties that are not actually ISPs (particularly when those parties are 'managed' via IP address block reputation- based countermeasures.) As long as the community recognizes that the two requests above (ISP, faux ISP) look nearly identical at first, we can perform whatever level of verification is (or is not) desired, and would definitely encourage discussion of the verification topic on this list. Thanks! /John John Curran President and CEO ARIN From bill at herrin.us Mon Apr 30 11:51:40 2012 From: bill at herrin.us (William Herrin) Date: Mon, 30 Apr 2012 11:51:40 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On 4/28/12, Jimmy Hess wrote: > Well, I will say, that /32 dedicated user address assignments > merit more scrutiny. > Dynamic address pools are different, because no IP address is > permanently assigned. Jimmy, Wave your hands and start the smoke machine before you say that, 'cause it's pure magic. Once upon a time there was a meaningful difference (from an address consumption perspective) between a static assignment and a dynamic pool. Back in the dialup days, a dynamic pool usually meant a many to one relationship between customers and IP addresses and the "many" could be as many as 100 customers per address consumed. Dialup pools still exist but the majority of today's so-called "dynamic" address pools are DHCP on a LAN or the pool for a cable modem head end or the pool for a DSLAM. Because theses customers are in the "always on" category, the relationship between customer and address falls to worse than 1:1. Because the pool size is not hard tied to the number of customers which access it, you actually need extra addresses for system headroom, more total than if you had explicitly assigned each a /32. >From a pragmatic address-utilization perspective, the difference between dynamic and static pools has ceased to exist. Whether the user hops between addresses or keeps a single address, they indefinitely hold a /32. > The question then is not "is this customer actually using the > resource"; but, are there enough (also identifiable) customers > served by the pool, with a growth rate to justify a pool of that size. The question is: do we want to accept ARIN prying in to our customers who use a single IP address or is that a step too far? Don't overlook: ARIN must implement their procedures in an even-handed way. If they make a habit of inquiring into /32 static assignments but not inquiring in to functionally identical (possibly more consumptive) dynamic pools, as the address pool tightens they will be sued for the favoritism. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From info at arin.net Mon Apr 30 11:57:49 2012 From: info at arin.net (ARIN) Date: Mon, 30 Apr 2012 11:57:49 -0400 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> Message-ID: <4F9EB67D.8080005@arin.net> ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found 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 Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers Proposal Originator: Kevin Blumberg Proposal Version: 1 Date: 30 April 2012 Proposal type: remove Policy term: permanent Policy statement: Remove the entire subsection 4.3.6.2 "Additional Assignments for Small Multihomers". Rationale: The policy has had the unintended effect of freezing small multi homed end users from being able to return to ARIN for additional assignments. The requirement to renumber out of space is unique and is applying an undue burden of renumbering what would be an organization's core infrastructure. Timetable for implementation: immediate From Marla.Azinger at FTR.com Mon Apr 30 12:01:38 2012 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Mon, 30 Apr 2012 12:01:38 -0400 Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: References: Message-ID: <2E2FECEBAE57CC4BAACDE67638305F104C7D483EC0@ROCH-EXCH1.corp.pvt> The /29 requirement is addressing public records not showing proof to ARIN staff that you actually utilized all your address space. Regarding proof of DHCP pools. Be glad they didn't ask. They now request mapping records as well. Showing ARIN staff proof you used address space is different than policy governing what is required to be visible to the public. If ARIN staff didn't ask for forms of proof then justification would be a total joke. Marla Azinger Sr Data Engineer Address Management & Planning -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Thursday, April 26, 2012 1:36 PM To: ARIN PPML Subject: [arin-ppml] Revealing /32 customers? Hi folks, Paraphrasing a private message I received during a recent NANOG discussion: "We have roughly 66 /32 customer assignments and a /24 for management addresses (switches, waps, wireless backhauls, servers, etc). Also a number of large assignments to DHCP pools. ARIN not only asked for the 66 customer names once, when the company went back to ask for additional space after renumbering, they were asked for it again. ARIN asked nothing concerning the DHCP pools, which by themselves qualified the address space." My understanding was that our consensus policy is that an ISP is expected to reveal customer information about assignments of /29 and larger. So, this brings to mind two questions: 1. Do current ARIN staff procedures have situations which place a mandatory requirement for an ISP to reveal (under NDA or otherwise) customers to whom less than a /29 of address spaces has been assigned? By "mandatory" I mean that ARIN staff will not accept an alternate form of demonstration that the /32 assignments are in use. The customer identities are required. 2. If ARIN staff procedures are in fact as described in #1, from which NRPM policies do those particular procedures derive? Thanks, 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. This communication is confidential. Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer. From jbates at brightok.net Mon Apr 30 12:01:48 2012 From: jbates at brightok.net (Jack Bates) Date: Mon, 30 Apr 2012 11:01:48 -0500 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> References: <0743E1C1-C227-4B1F-B728-468F46D052AB@arin.net> <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> Message-ID: <4F9EB76C.7080706@brightok.net> On 4/30/2012 10:02 AM, John Curran wrote: > If a significant amount of your utilization is based on discrete customer > assignments (and we have no record of your previous utilization rates, as > is common for an organization coming directly to ARIN for the first time), > you are likely to be asked followup questions to verify that some of the > individual customer assignments were done for actual customers. > > Also, if you're not actually an ISP serving customers, but instead a nice > facade which has been created and carefully developed over several months for > the sole purpose of getting a PI-allocation IPv4 address block out of ARIN, > That's the part that confused me, John. In my customer's case, they were renumbering from PA (mine) to PI. While their initial request was the usual outrageous size, they were perfectly happy with the ARIN return of "this is what you qualify for". They had years (roughly 8-10?) of SWIP assignments and growth to reach the /21+ they qualified for. They are shifting models, multi-homing, and wanted their own PI space. In response, ARIN pushed a much stiffer verification than would be done with PA space, and I'm not even sure why; given it's slow growth over the years. Roughly 200 assignments (2/3 of which was infrastructure addressing) doesn't seem significant out of a /21 for a small telco ISP. If they had objected, they would have been stuck with my PA space, which ARIN wouldn't have required me to obtain customer information from them on; just the usual counts. Jack From bill at herrin.us Mon Apr 30 12:06:14 2012 From: bill at herrin.us (William Herrin) Date: Mon, 30 Apr 2012 12:06:14 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <0743E1C1-C227-4B1F-B728-468F46D052AB@arin.net> References: <0743E1C1-C227-4B1F-B728-468F46D052AB@arin.net> Message-ID: On 4/28/12, John Curran wrote: > On Apr 28, 2012, at 3:50 PM, William Herrin wrote: >> Of the four folks across this conversation who've levied complaints >> about ARIN asking for customer identities for /32 users, none have >> expressed that ARIN inquired into customer identities for their >> dynamic pools and one expressly stated that ARIN didn't ask about the >> much larger dynamic pools at all. Four does not make a statistical >> sample but it does suggest a pattern. > > Indeed, it is an outline of a pleasant pattern that such information > isn't generally needed nor requested. Hi John, That's the positive spin. The negative spin is that it outlines a pattern of bias in which /32 assignments made and revoked with one particular set of automation tools are distinctly more likely to get a free pass than other perfectly legitimate /32 assignment processes. >> Per your statement above, ARIN considers itself at liberty to inquire >> into the personally identifiable information (PII) of the smallest and >> most ephemeral consumers of addresses among the ISP's customers during >> an ISP's application for addresses. Is that correct? > > Interesting phrasing, but could be literally correct (even if taken > to extreme...) In other words, "yes, that's correct." ARIN won't make a habit of trolling your customer database but the PII for any particular customer is subject to a demand for production with the expectation that refusal may result in failing ARIN's audit. >> Folks, is that what we want? > > A most excellent question, and one which the community should > definitely discuss. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From hannigan at gmail.com Mon Apr 30 12:16:05 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 30 Apr 2012 12:16:05 -0400 Subject: [arin-ppml] Revealing /32 customers? In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F104C7D483EC0@ROCH-EXCH1.corp.pvt> References: <2E2FECEBAE57CC4BAACDE67638305F104C7D483EC0@ROCH-EXCH1.corp.pvt> Message-ID: Agreed, although that would seem to imply that it might make sense to rid network operators of the /29 documentation requirement as a counter balance to the cost of providing such detailed information. I know that the group of us who are "interested" in Section 12 would probably be amenable to a reasonable tightening of the requirements facing ARIN while still maintaining their ability to "do their job". Best, -M< On Mon, Apr 30, 2012 at 12:01 PM, Azinger, Marla wrote: > The /29 requirement is addressing public records not showing proof to ARIN > staff that you actually utilized all your address space. > > Regarding proof of DHCP pools. Be glad they didn't ask. They now request > mapping records as well. > > Showing ARIN staff proof you used address space is different than policy > governing what is required to be visible to the public. If ARIN staff > didn't ask for forms of proof then justification would be a total joke. > > Marla Azinger > Sr Data Engineer > Address Management & Planning > > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of William Herrin > Sent: Thursday, April 26, 2012 1:36 PM > To: ARIN PPML > Subject: [arin-ppml] Revealing /32 customers? > > Hi folks, > > Paraphrasing a private message I received during a recent NANOG discussion: > > "We have roughly 66 /32 customer assignments and a /24 for management > addresses (switches, waps, wireless backhauls, servers, etc). Also a number > of large assignments to DHCP pools. > > ARIN not only asked for the 66 customer names once, when the company went > back to ask for additional space after renumbering, they were asked for it > again. ARIN asked nothing concerning the DHCP pools, which by themselves > qualified the address space." > > > My understanding was that our consensus policy is that an ISP is expected > to reveal customer information about assignments of /29 and larger. So, > this brings to mind two questions: > > 1. Do current ARIN staff procedures have situations which place a > mandatory requirement for an ISP to reveal (under NDA or otherwise) > customers to whom less than a /29 of address spaces has been assigned? > By "mandatory" I mean that ARIN staff will not accept an alternate form of > demonstration that the /32 assignments are in use. The customer identities > are required. > > 2. If ARIN staff procedures are in fact as described in #1, from which > NRPM policies do those particular procedures derive? > > Thanks, > 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. > > This communication is confidential. Frontier only sends and receives > email on the basis of the terms set out at > http://www.frontier.com/email_disclaimer. > _______________________________________________ > 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 bill at herrin.us Mon Apr 30 12:19:47 2012 From: bill at herrin.us (William Herrin) Date: Mon, 30 Apr 2012 12:19:47 -0400 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <4F9EB67D.8080005@arin.net> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> Message-ID: On 4/30/12, ARIN wrote: > ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers > > Policy statement: > > Remove the entire subsection 4.3.6.2 "Additional Assignments for Small > Multihomers". Opposed. Prefixes announced into BGP are expensive and everybody except the originator bears the cost. For a decade limits were placed at /20 or /22 in order to indirectly suppress the route count. The policy which finally allowed access to /24's balanced this need by requiring such /24's to be returned in order to get more addresses. It was well understood that end users initially receiving a /24 would encounter the grave difficulties associated with renumbering when their address needs grew. This compromise was deemed better than freezing them out of ARIN addresses entirely until they reached the larger threshold size. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dburk at burkov.aha.ru Mon Apr 30 11:36:05 2012 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Mon, 30 Apr 2012 19:36:05 +0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> References: <0743E1C1-C227-4B1F-B728-468F46D052AB@arin.net> <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> Message-ID: <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> John, sorry for interruption. I slightly concerned personally. During our roundtable meeting in February I was shocked by FBI guy comments on their expectations on future quality of RIR's registry databases. I personally think that it is not job of RIR's to satisfy all CALEA or any others reqs for assignments details especially did by our members. In your case - it seems that you can easily lose the feeling that you are not national registry - but Regional Registry. It can be a big mistake even in such polite manner to interpret badly (flexible) defined policies to satisfy local LEAs expectations. It can be dangerous precedent for all RIRs. May be I mistaken- but in result of all discussions of last years - for me it seems that you (ARIN) are possible under the more pressure of some guys and sometimes it is hard to ignore all their requests - what I can understand. I saw also that community splitted in their views - but it seems there are no still reason to concentrate data (PII) in one place. It could be a bad precedent for RIRs that someone will concentrate such power of information. Dima On Apr 30, 2012, at 7:02 PM, John Curran wrote: > On Apr 30, 2012, at 10:14 AM, Jack Bates wrote: > >> This was my big concern, and I did warn (after the fact) the telco that didn't talk to their lawyer before sending the information to ARIN (probably didn't get an NDA, either). They were most likely audited for asking for some obscene CIDR block initially, but that probably isn't unusual out of people switching from PA to PI. In their ignorance, they ask for someone big and cool and ARIN corrects them in the followup for what they justify. >> >> However, as an ISP that serve's ISPs, I've never been requested to go to my ISP customers and ask them for this information. Some of them would laugh in my face. I wonder if this doesn't create an extra hardship between PI and PA justifications, and if that is something that is desired. >> >> Also, are we just picking on the little guy, while some of the largest networks (as mentioned elsewhere) are leaving huge blocks of networks SWIP'd after they've been released and possibly asking for more space? The smaller ISPs are more likely to have a 4-30% static assignment ratio compared to the larger ISPs, which seems to indicate they are more likely to get PII detail audits. Only ARIN can confirm what size of aggregate allocated space tends to generate this kind of detail, though. > > Jack - > > If a significant amount of your utilization is based on discrete customer > assignments (and we have no record of your previous utilization rates, as > is common for an organization coming directly to ARIN for the first time), > you are likely to be asked followup questions to verify that some of the > individual customer assignments were done for actual customers. > > Also, if you're not actually an ISP serving customers, but instead a nice > facade which has been created and carefully developed over several months for > the sole purpose of getting a PI-allocation IPv4 address block out of ARIN, > and now asserting a significant amount of utilization is based on unnamed > customer assignments, you are also likely to be asked followup questions > to verify the some of the individual customer assignments. (Note - If you > do get an ARIN allocation for your "ISP", you're on your way to then having > lots more imaginary firms rotating in and our as customers in the process > getting your real business done, e.g. innovative marketing efforts, and by > 'disconnecting those bad customers' repeatedly you've probably got a year or > two until folks realize that you & your customers are one and the same...) > > While ARIN is concerned about IP address management, there are some interesting > side effects of allowing ISP allocations to parties that are not actually ISPs > (particularly when those parties are 'managed' via IP address block reputation- > based countermeasures.) > > As long as the community recognizes that the two requests above (ISP, faux ISP) > look nearly identical at first, we can perform whatever level of verification is > (or is not) desired, and would definitely encourage discussion of the verification > topic on this list. > > Thanks! > /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 Mon Apr 30 13:04:16 2012 From: jcurran at arin.net (John Curran) Date: Mon, 30 Apr 2012 17:04:16 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> References: <0743E1C1-C227-4B1F-B728-468F46D052AB@arin.net> <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net>, <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> Message-ID: <68767A02-BBC6-43D2-B62F-947829343038@arin.net> On Apr 30, 2012, at 12:37 PM, "Dmitry Burkov" wrote: > It can be a big mistake even in such polite manner to interpret badly (flexible) defined policies to satisfy > local LEAs expectations. It can be dangerous precedent for all RIRs. Dmitri - ARIN does not have any expectations to meet except those set by the community via policy. Law enforcement has a voice in the process just as anyone in the public discussion. Verification of utilization orginates from the need to maintain appropriate stewardship, not any requirement from government or LEA. > May be I mistaken- but in result of all discussions of last years - for me it seems that you (ARIN) are possible under the more pressure of some guys and sometimes it is hard to ignore all their requests - what I can understand. ARIN doesn't experience any particular pressures in this area; we simply direct any desires for new policy to the community policy development process. > I saw also that community splitted in their views - but it seems there are no still reason to concentrate data (PII) in one place. Full agreement; the detailed data that we request should be retained no longer than necessary, and I have taken an action item to review how we go about retaining such information for an appropriate period. Thanks! /John John Curran President and CEO ARIN From info at arin.net Mon Apr 30 13:18:07 2012 From: info at arin.net (ARIN) Date: Mon, 30 Apr 2012 13:18:07 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - April 2012 Message-ID: <4F9EC94F.3090907@arin.net> In accordance with the ARIN Policy Development Process the ARIN Advisory Council (AC) held a meeting on 25 April 2012 and made decisions about several draft policies. The AC moved the following draft policies to last call (they will be posted separately to last call): ARIN-2012-1: Clarifying requirements for IPv4 transfers ARIN-2012-3: ASN Transfers The following remains on the AC's docket: ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement The AC abandoned the following: ARIN-2011-5: Shared Transition Space for IPv4 Address Extension ARIN-2011-7: Compliance Requirement ARIN-2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool The AC provided the following in regards to ARIN-2011-5: "After much debate, the proposal in question was sent forward to the Board for implementation, this resulted in conversations with the IETF and the publishing of RFC 6598, which requested the space be allocated via IANA. This has been done, and therefore policy action by ARIN is no longer necessary. The board referred the policy back to the AC, and the AC hereby abandons the policy to successfully conclude its policy life-cycle. The AC thanks the community for its support in this endeavor. Regarding ARIN-2011-7, the AC stated, "After several revisions and much work with both the policy originators and the general community, this policy has still been unable to gain a positive consensus. As such, it is the belief of the AC that no further productive work can be done with this specific policy and we have thus voted to abandon it. We're happy to work on future policy to meet the needs of the community. The AC invites community members who wish to participate in future policy development to contribute their ideas or policy proposals." Regarding ARIN-2012-4, the AC stated, "The abandonment motion was based on two main points: * Approximately an even split in the community, both on PPML and at ARIN XXIX, favoring/opposing the measure. * Concern about losing soft landing aspects of a 3 month window (soft landing procedures are in effect at other RIRs)." The AC abandoned ARIN-2011-5, ARIN-2011-7, and ARIN-2012-4 and kept ARIN-2012-2 on their docket. Anyone dissatisfied with these decisions may initiate a petition. The petition to advance these draft policies would be the "Last Call 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 Mon Apr 30 13:18:39 2012 From: info at arin.net (ARIN) Date: Mon, 30 Apr 2012 13:18:39 -0400 Subject: [arin-ppml] ARIN-2012-1: Clarifying Requirements for IPv4 Transfers - Last Call Message-ID: <4F9EC96F.8090305@arin.net> The ARIN Advisory Council (AC) met on 25 April 2012 and decided to send the following draft policy to last call: ARIN-2012-1: Clarifying Requirements for IPv4 Transfers Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. Last call for 2012-1 will expire on 14 May 2012. 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) ## * ## Draft Policy ARIN-2012-1 Clarifying Requirements for IPv4 Transfers Date: 11 April 2012 Replace Section 8.3 with 8.3 Transfers between Specified Recipients within the ARIN Region. In addition to transfers under section 8.2, IPv4 numbers resources may be transferred according to the following conditions. Conditions on source of the transfer: * The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. * The source entity will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. * The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers. * The minimum transfer size is a /24 Conditions on recipient of the transfer: * The recipient must demonstrate the need for up to a 24 month supply of IP address resources under current ARIN policies and sign an RSA. * The resources transferred will be subject to current ARIN policies. Add Section 8.4 Inter-RIR Transfers to Specified Recipients Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies. Conditions on source of the transfer: * The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources. * Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration. * Source entities within the ARIN region will not be eligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. * Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers. * The minimum transfer size is a /24. Conditions on recipient of the transfer: * The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR. * Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received. * Recipients within the ARIN region must demonstrate the need for up to a 24 month supply of IPv4 address space. * The minimum transfer size is a /24 Rationale: The original text of this proposal attempted to clarify the requirements of an IPv4 address transfer while protecting any resources remaining in the ARIN free pool. This revision is a result of feedback from the mailing list, ARIN Staff, and discussions with the original author. The one key point that has been removed from the original text is that a needs based review remains in place. The current text attempts to retain the original concepts of protecting an ARIN free pool, and incorporating it with the point of bringing resources under RSA. The resulting text attempts to put safeguards in place on the practice of paid transfers by creating a black out period for transfers and requests to the free pool. The text also tries to incorporate discussions regarding inter-RIR transfers and come up with language that includes the free pool protections for transfers in and out of the Region. Timetable for implementation: immediate. From info at arin.net Mon Apr 30 13:19:01 2012 From: info at arin.net (ARIN) Date: Mon, 30 Apr 2012 13:19:01 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call Message-ID: <4F9EC985.1030503@arin.net> The ARIN Advisory Council (AC) met on 25 April 2012 and decided to send the following draft policy to last call: ARIN-2012-3: ASN Transfers Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. Last call for 2012-3 will expire on 14 May 2012. 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) ## * ## Draft Policy ARIN-2012-3 ASN Transfers Date: 14 March 2012 Policy statement: In NRPM 8.3, replace "IPv4 number resources" with "IPv4 number resources and ASNs". Rationale: There are legitimate use cases for transferring ASNs, and no significant downsides (identified to date) of allowing it. Timetable for implementation: Immediate From mike at nationwideinc.com Mon Apr 30 14:55:52 2012 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 30 Apr 2012 14:55:52 -0400 Subject: [arin-ppml] ARIN-2012-1: Clarifying Requirements for IPv4 Transfers- Last Call In-Reply-To: <4F9EC96F.8090305@arin.net> References: <4F9EC96F.8090305@arin.net> Message-ID: <5B1E79BCC36148DDA6B68526DE52F35A@MPC> As the author of the original proposal, I would like to thank the AC shepherds and those who helped shape the draft policy through feedback. Although I am unhappy with the fact that a needs test remains in place for 8.3 transfers, I am happy that this draft policy could help open the door to Inter-regional transfers. I am also happy that the justification window is longer for 8.3 transfers (24 months), and separately that the RSA has been changed to limit ARIN's ability to revoke for utilization, which was another part of the original Prop-151. This last should help bring more unused addresses to market as it assuages any fear (founded or unfounded) of Number Resource holders that their addresses will be revoked by ARIN should they be openly offered for sale. Finally I am happy that this Draft Proposal incorporates protections of the free pool. I am glad to express support. Regards, Mike Burns -----Original Message----- From: ARIN Sent: Monday, April 30, 2012 1:18 PM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN-2012-1: Clarifying Requirements for IPv4 Transfers- Last Call The ARIN Advisory Council (AC) met on 25 April 2012 and decided to send the following draft policy to last call: ARIN-2012-1: Clarifying Requirements for IPv4 Transfers Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. Last call for 2012-1 will expire on 14 May 2012. 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) ## * ## Draft Policy ARIN-2012-1 Clarifying Requirements for IPv4 Transfers Date: 11 April 2012 Replace Section 8.3 with 8.3 Transfers between Specified Recipients within the ARIN Region. In addition to transfers under section 8.2, IPv4 numbers resources may be transferred according to the following conditions. Conditions on source of the transfer: * The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. * The source entity will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. * The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers. * The minimum transfer size is a /24 Conditions on recipient of the transfer: * The recipient must demonstrate the need for up to a 24 month supply of IP address resources under current ARIN policies and sign an RSA. * The resources transferred will be subject to current ARIN policies. Add Section 8.4 Inter-RIR Transfers to Specified Recipients Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies. Conditions on source of the transfer: * The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources. * Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration. * Source entities within the ARIN region will not be eligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. * Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers. * The minimum transfer size is a /24. Conditions on recipient of the transfer: * The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR. * Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received. * Recipients within the ARIN region must demonstrate the need for up to a 24 month supply of IPv4 address space. * The minimum transfer size is a /24 Rationale: The original text of this proposal attempted to clarify the requirements of an IPv4 address transfer while protecting any resources remaining in the ARIN free pool. This revision is a result of feedback from the mailing list, ARIN Staff, and discussions with the original author. The one key point that has been removed from the original text is that a needs based review remains in place. The current text attempts to retain the original concepts of protecting an ARIN free pool, and incorporating it with the point of bringing resources under RSA. The resulting text attempts to put safeguards in place on the practice of paid transfers by creating a black out period for transfers and requests to the free pool. The text also tries to incorporate discussions regarding inter-RIR transfers and come up with language that includes the free pool protections for transfers in and out of the Region. Timetable for implementation: immediate. _______________________________________________ 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 jrhett at netconsonance.com Mon Apr 30 17:51:01 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 30 Apr 2012 14:51:01 -0700 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> Message-ID: On Apr 30, 2012, at 9:19 AM, William Herrin wrote: > Opposed. > > Prefixes announced into BGP are expensive and everybody except the > originator bears the cost. For a decade limits were placed at /20 or > /22 in order to indirectly suppress the route count. > > The policy which finally allowed access to /24's balanced this need by > requiring such /24's to be returned in order to get more addresses. It > was well understood that end users initially receiving a /24 would > encounter the grave difficulties associated with renumbering when > their address needs grew. This compromise was deemed better than > freezing them out of ARIN addresses entirely until they reached the > larger threshold size. While I agree with everything you said here, I want to raise a question. The point of these limits was to avoid the old routers hitting the 192k wall, and later the 256k wall. Three years ago everyone with routers that could only handle 256k routes hit the wall anyway. It's far past that time, and I really don't know of any production gear still operating in a defaultless mode which accepts less than a million routes. Anyone with older gear is running crippled anyway, so we don't need to protect them. Have these concerns been obsoleted? -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrhett at netconsonance.com Mon Apr 30 17:52:20 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 30 Apr 2012 14:52:20 -0700 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: <94FC8416-F1CE-4C1F-BC03-98859BA9D94B@netconsonance.com> On Apr 27, 2012, at 8:44 PM, William Herrin wrote: > Have you considered the double-standard in place here? > > Where you specify a DHCP pool for always-on DSL users who may well > hold a particular address for months, ARIN does not consider itself at > liberty to inquire into the customers' identities and is able > "validate" the use regardless. Yet if you explicitly assign them > /32's... I'm not aware of any double standard. I've had to supply customer lists using dynamic pools as well. It was neither harder nor easier than supplying lists of customers using /32s. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Mon Apr 30 18:26:59 2012 From: bill at herrin.us (William Herrin) Date: Mon, 30 Apr 2012 18:26:59 -0400 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> Message-ID: On 4/30/12, Jo Rhett wrote: > On Apr 30, 2012, at 9:19 AM, William Herrin wrote: >> Prefixes announced into BGP are expensive and everybody except the >> originator bears the cost. For a decade limits were placed at /20 or >> /22 in order to indirectly suppress the route count. >> >> The policy which finally allowed access to /24's balanced this need by >> requiring such /24's to be returned in order to get more addresses. It >> was well understood that end users initially receiving a /24 would >> encounter the grave difficulties associated with renumbering when >> their address needs grew. This compromise was deemed better than >> freezing them out of ARIN addresses entirely until they reached the >> larger threshold size. > > While I agree with everything you said here, I want to raise a question. > The point of these limits was to avoid the old routers hitting the 192k > wall, and later the 256k wall. Three years ago everyone with routers that > could only handle 256k routes hit the wall anyway. It's far past that time, > and I really don't know of any production gear still operating in a > defaultless mode which accepts less than a million routes. Anyone with > older gear is running crippled anyway, so we don't need to protect them. > > Have these concerns been obsoleted? If you're running IPv6, your wall is short of 1M routes. I don't know if that means 512k or 768k but the exact number is well short. So, the wall has moved but only so far. C & J could build the next generation of routes to 10M instead of 2M if the demand was there. You can build a route processor that can keep up and you can also build a TCAM that can hold it. It wouldn't break the bank but it likely would double the cost. Fortunately, 10M is enough to satisfy the maximum probable disaggregation of the IPv4 table in any scenario that doesn't involve widespread abandonment of the /24 boundary. However... if the demand pattern shifts too fast then C & J both could be stuck without shipping product lines capable of supporting more than about double the current IPv4 routing table or without enough built product ready to ship. Somewhere around 150k mostly very expensive routers have to be upgraded or replaced before we hit the next wall. Could be dicey. Short answer to your question: no, the concerns have not been obsoleted. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Mon Apr 30 19:16:33 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 30 Apr 2012 18:16:33 -0500 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: On 4/30/12, William Herrin wrote: [snip] > From a pragmatic address-utilization perspective, the difference > between dynamic and static pools has ceased to exist. Whether the user > hops between addresses or keeps a single address, they indefinitely > hold a /32. No. The customer holds a /32 as long as they have a valid DHCP lease assigned to their connected equipment. DHCP leases have finite durations, and will expire soon after the customer disconnects; therefore, these are not indefinitely assigned. Only the overall pool is indefinitely assigned, renumbering or resizing the pool is simple, since addresses are already dynamic, therefore capacity management of the pool becomes simple and easily manageable using simple monitoring tools. Each and every DHCP assignment will definitively cease to exist as soon as the customer cancels service. Which makes assignments inherently definite in duration, and is one of the benefits of implementing DHCP pools for customer management, and minimal numbers of static assignments --- administrative overhead of IP address management is reduced. When ISPs manage /32 allocations manually, instead of utilizing a DHCP pool, even when the allocations are properly documented, periodic manual efforts, with a level of expense similar to address renumbering, is required to "clean up" and relinquish old no longer used allocations. In addition when old cancelled customers with /32 assignments do not happen to be contiguous IP addresses, it is tempting to a service provider to fail to renumber and consolidate existing /32 assignments, even when there are sufficient numbers of unused (but fragmented) IP addresses to satisfy the need for their next 3 months of /28 allocations. > The question is: do we want to accept ARIN prying in to our customers > who use a single IP address or is that a step too far? ARIN has a duty to take reasonable steps to validate justifications for address assignment. ARIN is not "prying", because information requests are not merely to satisfy some idle curiosity of ARIN's, they are actually required to reasonably distinguish between improper applications and valid justifications. > Don't overlook: ARIN must implement their procedures in an even-handed > way. If they make a habit of inquiring into /32 static assignments but > not inquiring in to functionally identical (possibly more consumptive) > dynamic pools, as the address pool tightens they will be sued for the > favoritism. ARIN is not necessarily required to provide equal scrutiny to all systems that different ISPs use for providing IP addresses to end users. Especially when certain methods may more commonly provide greater efficiency and scalability. DHCP pools require spare capacity to accomadate growth. /29 and /32 assignments require spare capacity to make new assignments, and in addition larger amounts of IP address space becomes wasted and unusable due to IP address assignment space fragmentation. And potential lax cleanup policies of many providers. Suggest direct assignments should receive specific scrutiny. (Not that justification for dynamic pool sizes should not be subject to verification) Regards, -- -JH From mysidia at gmail.com Mon Apr 30 19:49:23 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 30 Apr 2012 18:49:23 -0500 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <4F9EB67D.8080005@arin.net> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> Message-ID: On 4/30/12, ARIN wrote: I am opposed to the proposal that removes the requirement to renumber, without also changing the minimum allocation size for small multi-homers back to /22. The "freezing" of ARIN additional assignments is not an unintended effect, it is the express intent of the policy that changed the minimum allocation from /22 to /24; those organizations who obtained a /24 under this policy were aware, or should have been aware of the restriction, and had the option of obtaining address space from an upstream provider, if renumbering out of a /24 within a 1 year period would be an undue burden for that provider. The requirement to renumber should not be removed from existing /24s allocated under this policy; it is a provision that is relevant to serious concerns about routing table prefix count growth. > Rationale: > > The policy has had the unintended effect of freezing small multi homed > end users from being able to return to ARIN for additional assignments. > The requirement to renumber out of space is unique and is applying an > undue burden of renumbering what would be an organization's core > infrastructure. -- -JH From kevinb at thewire.ca Mon Apr 30 21:13:23 2012 From: kevinb at thewire.ca (Kevin Blumberg) Date: Tue, 1 May 2012 01:13:23 +0000 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> Message-ID: <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> Jimmy, At the last ARIN meeting in Vancouver and prior to that in Philadelphia staff pointed out that almost no one was coming back to ARIN for additional small end user assignment. I believe the number quoted was 1 in Philadelphia and 5 in Vancouver of which many hundreds of people had taken advantage of getting /23 and /24 initial allocations. While I understand the concern with the routing table, this policy has erred too far to one side. There is also the issue of compatibility with 8.3 transfers. If an end user were to go to the market for a /24 would they have to return the initial allocation and search for a /23 instead? Thanks, Kevin Blumberg > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Jimmy Hess > Sent: Monday, April 30, 2012 7:49 PM > To: ARIN > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-167 Removal of Renumbering > Requirement for Small Multihomers > > On 4/30/12, ARIN wrote: > > I am opposed to the proposal that removes the requirement to renumber, > without also changing the minimum allocation size for small multi-homers > back to /22. > > The "freezing" of ARIN additional assignments is not an unintended effect, it > is the express intent of the policy that changed the minimum allocation from > /22 to /24; those organizations who obtained a > /24 under this policy were aware, or should have been aware of the > restriction, and had the option of obtaining address space from an > upstream provider, if renumbering out of a /24 within a 1 year > period would be an undue burden for that provider. > > The requirement to renumber should not be removed from existing /24s > allocated under this policy; it is a provision that is relevant to > serious concerns about routing table prefix count growth. > > > > > > Rationale: > > > > The policy has had the unintended effect of freezing small multi homed > > end users from being able to return to ARIN for additional assignments. > > The requirement to renumber out of space is unique and is applying an > > undue burden of renumbering what would be an organization's core > > infrastructure. > > > -- > -JH > _______________________________________________ > 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 jeffrey.lyon at blacklotus.net Mon Apr 30 21:16:46 2012 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 30 Apr 2012 21:16:46 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <4F9EC985.1030503@arin.net> References: <4F9EC985.1030503@arin.net> Message-ID: On Mon, Apr 30, 2012 at 1:19 PM, ARIN wrote: > The ARIN Advisory Council (AC) met on 25 April 2012 and decided to > send the following draft policy to last call: > > ?ARIN-2012-3: ASN Transfers > > Feedback is encouraged during the last call period. All comments should > be provided to the Public Policy Mailing List. Last call for 2012-3 will > expire on 14 May 2012. 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) > > > ## * ## > > > Draft Policy ARIN-2012-3 > ASN Transfers > > Date: 14 March 2012 > > Policy statement: > > In NRPM 8.3, replace "IPv4 number resources" with "IPv4 number resources and > ASNs". > > Rationale: > > There are legitimate use cases for transferring ASNs, and no significant > downsides (identified to date) of allowing it. > > Timetable for implementation: Immediate > _______________________________________________ > 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. Strongly support. -- Jeffrey A. Lyon, CISSP President | (757) 304-0668 http://www.blacklotus.net Black Lotus Communications From mysidia at gmail.com Mon Apr 30 21:58:25 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 30 Apr 2012 20:58:25 -0500 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> Message-ID: On 4/30/12, Kevin Blumberg wrote: > At the last ARIN meeting in Vancouver and prior to that in Philadelphia > staff pointed out that almost no one was coming > back to ARIN for additional small end user assignment. I believe the number > quoted was 1 in Philadelphia and 5 in Vancouver > of which many hundreds of people had taken advantage of getting /23 and /24 > initial allocations. > > While I understand the concern with the routing table, this policy has erred > too far to one side. [snip] The policy was implemented September 2010. That is approximately 1.5 years ago. The fact hundreds of applicants occured showed success of the policy, not a failure or err'ing of the policy. If the renumbering requirement were considered too burdensome, no organizations would have applied for a /24 multi-homing assignment. Did ARIN go back to the organizations that received a /24 under 2010-2 more than 12 months ago, but did not make additional allocation requests, and survey them to determine if they obtained additional IP addresses from another source following their /24 allocation? There is an alternative explanation: perhaps they did not need more IP addresses, or they didn't need them very much. If they availed themselves of the new rule and carefully planned for the implications, its quite possible they had plans that would avoid the need to renumber within the foreseeable future or make it worth it by the time they needed to. There really is no indication the policy has err'd in this case -- it seems to have been successful, there is limited routing table impact. It is not clear what kind of impact removing the renumbering requirement would have on number of applications; I would anticipate the number of /24 small ISP multihoming applications could increase massively, due to a large number of organizations seeing removal of the renumber requirement as a reason to go to ARIN for PI instead of upstreams. -- -JH From bill at herrin.us Mon Apr 30 22:22:03 2012 From: bill at herrin.us (William Herrin) Date: Mon, 30 Apr 2012 22:22:03 -0400 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> Message-ID: On 4/30/12, Bill Darte wrote: > May I ask for the record if you believe that the circumstances have changed > as we approach run out of free pools throughout the world and the > expectation may be that smaller blocks will need to be routed in order to > enable new entrants into the Internet. Hi Bill, The circumstances continue to evolve and frankly I'd be interested to learn what the ground game at APNIC looks like now that they've been cruising without a free pool for a while. For the moment, though, I thought it was a superb idea to lower the minimum assignment to /24 with a renumbering requirement for assignments smaller than the prior minimum and I continue to think it's a great idea. > Why would allowing the recipients under 4.3.6.2 to keep the /24 and justify > another block be bad? Would it be an option to simply request that they > renumber into a larger block but accept some exceptions? Under what > circumstances would those exceptions be acceptable to you? I could probably be talked into the idea that an org may only hold a single assignment smaller than /22 but is not required to renumber out of that assignment when requesting a /22 or larger. In other words, you can't just request another /24 and grow by costly little nibbles at the RIB. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Mon Apr 30 22:38:03 2012 From: bill at herrin.us (William Herrin) Date: Mon, 30 Apr 2012 22:38:03 -0400 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> Message-ID: On 4/30/12, Kevin Blumberg wrote: > At the last ARIN meeting in Vancouver and prior to that in Philadelphia > staff pointed out that almost no one was coming > back to ARIN for additional small end user assignment. I believe the number > quoted was 1 in Philadelphia and 5 in Vancouver > of which many hundreds of people had taken advantage of getting /23 and /24 > initial allocations. Hi Kevin, How does that compare with end users receiving /22's who subsequently return for more addresses? My understanding from prior ARIN reports was that end users requesting the smallest permitted assignments rarely returned for more even before this policy was enacted. Incidentally, one of the orgs I support holds a /23 under the policy. If it needs to graduate to a /22 while the policy is on the books, it'll have to renumber. Which means I personally will have to deal with the pain. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004