From jrhett at netconsonance.com Tue May 1 12:18:26 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 1 May 2012 09:18:26 -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> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> Message-ID: <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> On Apr 30, 2012, at 7:38 PM, William Herrin wrote: > it'll have to renumber. Which means I personally will have to deal > with the pain. Now I'm going to go back to the devil's advocate side again, and also point out that the pain of renumbering is not the horror, the horror, the horror that everyone makes it out to be. Painful, and sometimes slow when there are lots of external dependancies, but it's really not as bad as people make it out to be ;-) -- 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 Tue May 1 12:52:46 2012 From: bill at herrin.us (William Herrin) Date: Tue, 1 May 2012 12:52:46 -0400 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> Message-ID: On 5/1/12, Jo Rhett wrote: > On Apr 30, 2012, at 7:38 PM, William Herrin wrote: >> it'll have to renumber. Which means I personally will have to deal >> with the pain. > > Now I'm going to go back to the devil's advocate side again, and also point > out that the pain of renumbering is not the horror, the horror, the horror > that everyone makes it out to be. Painful, and sometimes slow when there are > lots of external dependancies, but it's really not as bad as people make it > out to be ;-) Hi Jo, I have to disagree with you there. Renumbering is every bit as bad as people say and then some. First there's DNS pinning. Because of DNS pinning, web browsers won't follow your new IP address when the DNS TTL runs out. In some cases, not until the browser is completely stopped and restarted, such as with a reboot. If you keep the old IP address alive, you'll notice the occasional request from a perfectly ordinary web browser come in months after you changed the IP. Then there's the email spam control systems. They're heavily based on IP addresses. Start emitting a lot of email from an address that didn't previously do so? Spammer. Blocked. And tracking down all the various whitelist and feedback loops (all of them IP based) that you talked your way in to over the years is a major chore. And that's before you deal with all the myriad custom applications where the developer was too inexperienced or too lazy to implement DNS in the first place. It may not be possible to overstate just how bad renumbering is. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmaimon at chl.com Tue May 1 12:49:38 2012 From: jmaimon at chl.com (Joe Maimon) Date: Tue, 01 May 2012 12:49:38 -0400 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> Message-ID: <4FA01422.6030402@chl.com> Jo Rhett wrote: > On Apr 30, 2012, at 7:38 PM, William Herrin wrote: >> it'll have to renumber. Which means I personally will have to deal >> with the pain. > > Now I'm going to go back to the devil's advocate side again, and also > point out that the pain of renumbering is not the horror, the horror, > the horror that everyone makes it out to be. Painful, and sometimes slow > when there are lots of external dependancies, but it's really not as bad > as people make it out to be ;-) > > -- > Jo Rhett > Net Consonance : net philanthropy to improve open source and internet > projects. > > I suspect it would be more significant to note which of us have not interacted with a significant renumbering event, rather than the opposite. The less often people renumber the more painful it is likely to be when they do so, not just for themselves, but for everyone else who may be faced with it at one point. This is due to the pain being wholly self inflicted, in that dependencies are formed and grown under the assumption of address longevity. To a much larger extent than normally practiced, varying amounts of this self inflicted pain is avoidable with forethought, planning, and self discipline. Attributes which are usually far less prevalent then they should be. Attributes which are not recognized as valuable without the understanding and experience of renumbering, and that it is neither always predictable nor avoidable. The greater the emphasis placed on preparing for renumbering as opposed to avoiding it, the more likely that workable technology that properly abstracts the task is developed and deployed. How renumber-able are the typical IPv6 deployments? Joe From scottleibrand at gmail.com Tue May 1 13:39:55 2012 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 1 May 2012 10:39:55 -0700 Subject: [arin-ppml] IPv6 Renumbering (Was: Re: ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers) Message-ID: On Tue, May 1, 2012 at 9:49 AM, Joe Maimon wrote: > > I suspect it would be more significant to note which of us have not > interacted with a significant renumbering event, rather than the opposite. > > The less often people renumber the more painful it is likely to be when > they do so, not just for themselves, but for everyone else who may be faced > with it at one point. > > This is due to the pain being wholly self inflicted, in that dependencies > are formed and grown under the assumption of address longevity. > > To a much larger extent than normally practiced, varying amounts of this > self inflicted pain is avoidable with forethought, planning, and self > discipline. > > Attributes which are usually far less prevalent then they should be. > > Attributes which are not recognized as valuable without the understanding > and experience of renumbering, and that it is neither always predictable > nor avoidable. > > The greater the emphasis placed on preparing for renumbering as opposed to > avoiding it, the more likely that workable technology that properly > abstracts the task is developed and deployed. > > How renumber-able are the typical IPv6 deployments? With regard to IPv6, you might find the active IETF IPv6 Site Renumbering working group to be of interest: https://datatracker.ietf.org/wg/6renum/ -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Tue May 1 14:31:44 2012 From: info at arin.net (ARIN) Date: Tue, 01 May 2012 14:31:44 -0400 Subject: [arin-ppml] ARIN-prop-168 Promote 4byte ASN Usage In-Reply-To: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> Message-ID: <4FA02C10.7060408@arin.net> ARIN-prop-168 Promote 4byte ASN Usage 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-168 Promote 4byte ASN Usage Proposal Originator: Joe Maimon Proposal Version: 1.0 Date: 1 May 2012 Proposal type: Modify Policy term: Temporary Policy statement: Add section 5.2 5.2 Guidelines ARIN will issue AS Numbers under the following guidelines. 5.2.1 Unused ARIN will attempt to assign to the organization an AS Number which has neither been previously assigned nor used, as available. 5.2.2 Requests An organization may request from ARIN either a specific AS Number or type of AS Number, if available to ARIN. The organization must provide to ARIN's satisfaction technical justification for its request. ARIN may review the data directly with all involved parties. 5.2.3 Rectification ARIN, with suitable privacy considerations in place, may reuse the provided technical documentation in such public forums as it deems necessary to promote the rectification of the documented causes. 5.2.4 Restrictions Assignments received via 5.2.2 requests are additionally restricted from being transferred for a period of 24 months post assignment. 5.2.5 Release An organization can exchange the 5.2.2 number for a 5.2.1 number, after which time the restriction on transferring the assignment will be released. 5.2.6 Publication This section provides neither requirement nor recommendation that ARIN publicize its available AS Numbers. 5.2.7 Expiration ARIN may retire section 5.2 anytime after a period of 24 calendar months without any completed 5.2.2 requests. Rationale: Unless otherwise requested, providing an ASN with no baggage or history should be preferential to both the organization and to ARIN. The restrictions and clauses regarding technical justification are designed for the promotion of 4byte ASN uptake and preservation of 2byte ASN's for those who truly need them. Additionally, this may help to assist in resolving apparently pervasive obstacles in the ARIN region to using 4byte ASN's. Further, if an organization does have a valid technical justification for a specific AS Number that is available, for example, when a network was built with an ASN that was subsequently reclaimed due to accidental negligence or other similar cases, there is little benefit to ARIN refusing to provide the organization what it can show it needs. Should this policy become a relic (we hope), ARIN is expressly authorized to excise it. Timetable for implementation: Immediate. From jmaimon at chl.com Tue May 1 19:43:45 2012 From: jmaimon at chl.com (Joe Maimon) Date: Tue, 01 May 2012 19:43:45 -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> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <4FA01422.6030402@chl.com> Message-ID: <4FA07531.4040906@chl.com> Bill, I am not in favor of removing renumbering requirements at this time. Policy is too fresh to change it, data is too limited. Joe Bill Darte wrote: > Joe, > Are you for, or against the proposal? > bd > > On Tue, May 1, 2012 at 9:49 AM, Joe Maimon > wrote: > > > > Jo Rhett wrote: > > On Apr 30, 2012, at 7:38 PM, William Herrin wrote: > > it'll have to renumber. Which means I personally will have > to deal > with the pain. > > > Now I'm going to go back to the devil's advocate side again, > and also > point out that the pain of renumbering is not the horror, the > horror, > the horror that everyone makes it out to be. Painful, and > sometimes slow > when there are lots of external dependancies, but it's really > not as bad > as people make it out to be ;-) > > -- > Jo Rhett > Net Consonance : net philanthropy to improve open source and > internet > projects. > > > > I suspect it would be more significant to note which of us have > not interacted with a significant renumbering event, rather than > the opposite. > > The less often people renumber the more painful it is likely to be > when they do so, not just for themselves, but for everyone else > who may be faced with it at one point. > > This is due to the pain being wholly self inflicted, in that > dependencies are formed and grown under the assumption of address > longevity. > > To a much larger extent than normally practiced, varying amounts > of this self inflicted pain is avoidable with forethought, > planning, and self discipline. > > Attributes which are usually far less prevalent then they should be. > > Attributes which are not recognized as valuable without the > understanding and experience of renumbering, and that it is > neither always predictable nor avoidable. > > The greater the emphasis placed on preparing for renumbering as > opposed to avoiding it, the more likely that workable technology > that properly abstracts the task is developed and deployed. > > How renumber-able are the typical IPv6 deployments? > > > Joe > > _______________________________________________ > 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 Wed May 2 00:35:22 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 1 May 2012 21:35:22 -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> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> Message-ID: <8EB5E74F-9E9C-45BB-8608-8052E45610A4@netconsonance.com> On May 1, 2012, at 9:52 AM, William Herrin wrote: > First there's DNS pinning. Because of DNS pinning, web browsers won't > follow your new IP address when the DNS TTL runs out. In some cases, > not until the browser is completely stopped and restarted, such as > with a reboot. If you keep the old IP address alive, you'll notice the > occasional request from a perfectly ordinary web browser come in > months after you changed the IP. Yeah, so I just went through testing exactly this failover with extensive logs of every packet received and I can assure you that you won't miss a single HTTP hit that you care to receive. After 2 minutes post TTL expiration, the queries which were received at the old IPs were in the following list: 1. Yahoo search bots. It took about 4 hours for Yahoo search bots to update with new content. 2. Google search bots -- NOTE: they noticed and did index the new IPs right on schedule, they simply apparently also try the old IPs. There was no outage for Google, as new results showed up within 10 minutes. 3. A wide variety of other bots, some of whom claim to be versions of Internet Explorer that never existed. 4. A small variety of Internet sites using MSIE 6 or older. Querying back to the IPs on these sites, many appeared to be running MS DNS servers. You'll note that in our update we didn't see a single delayed query from Google Chrome, Firefox, Safari, MSIE, iOS, Android or Blackberry. Not a single one. No, DNS pinning is not a real issue. Yes, there are hits on the old address, and no you don't care about not receiving them. > Then there's the email spam control systems. They're heavily based on > IP addresses. Start emitting a lot of email from an address that > didn't previously do so? Spammer. Blocked. And tracking down all the > various whitelist and feedback loops (all of them IP based) that you > talked your way in to over the years is a major chore. I didn't say easy, and I didn't say 100% fall over. If you are a production e-mail site you know how to build trust in your IPs. I just did exactly this at $dayjob and it took me less than 14 days to get high-volume delivery working through all our channels. > And that's before you deal with all the myriad custom applications > where the developer was too inexperienced or too lazy to implement > DNS in the first place. I'm really not sure what this has to do with the top. > It may not be possible to overstate just how bad renumbering is. Bogus. Yes, it is hard. But we are all network engineers, and the work involved in migrations like this simply don't take that much effort. Do you find driving to the store and getting groceries equally hard? I do. It's a pain. But I do it all the time, it's how I feed myself / how I do my job as a network engineer. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From jrhett at netconsonance.com Wed May 2 00:39:06 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 1 May 2012 21:39:06 -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> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <4FA01422.6030402@chl.com> Message-ID: <5EADDA72-6338-4CAF-BF4E-F8D2A8C9D063@netconsonance.com> On May 1, 2012, at 3:35 PM, Bill Darte wrote: > Are you for, or against the proposal? I'm of deeply mixed opinion. I definitely understand the routing table slots issue. But I suspect it has less meaning now than it did before, due to everyone having to get much bigger tables in the last few years anyway. And there simply won't be *that* many /24s that acquire another /24. Before I consider that a threat, I'd like to see someone do the math real quick on how many /24s are there, and if every one of them got another /24 (if that is possible in the current free pool) what the table growth would be. I absolutely don't feel that "pain of renumbering" is now, nor should ever dictate policy. I don't think we should renumber without reason, but hell we all re-arrange when we move to a bigger house ;-) -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Wed May 2 03:58:54 2012 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 02 May 2012 00:58:54 -0700 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <4FA07531.4040906@chl.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <4FA01422.6030402@chl.com> <4FA07531.4040906@chl.com> Message-ID: <4FA0E93E.6010507@ipinc.net> I also disagree with the proposal. Having been through a major IPv4 renumbering with hundreds and hundreds of hosts involved, most of them NOT under my direct control, and several nameservers that had to be renumbered also, I simply do not feel that Kevin's assertions are valid. And on top of it he's talking END USER where the IP's ARE under the orgs control. Yes it's difficult to renumber. But, the org renumbering is getting something for their trouble - that is, they are getting more IP addresses. Many small end user orgs in the past have renumbered-and-returned just fine under 4.3.6.2 I don't see that suddenly in year 2012 that something new and special has come along that now makes renumbering impossible for these orgs. If an org cannot manage to expend a little effort to gain something then I question that they have even met the bar for an efficiently run organization that would put the public resource to good use in the first place. For extraordinary circumstances, you could write a proposal that would modify that section to allow the ARIN hostmaster discretion to extend the time that an end user could return the allocation in the case of extraordinary circumstances. We are already paying the hostmaster to make subjective judgements on what constitutes justification for additional addressing, so I don't see that it would be a burden for them to make one more subjective judgement on whether the end user org should be given an extended period of time to renumber and return due to special circumstances. But ARIN must put a barrier up to simply request-without-renumber otherwise the end user orgs will simply not do it. The proposal is throwing the baby out with the bathwater and has no recognition for the benefit to the community of forcing orgs to use contiguous subnets. Ted From Daniel_Alexander at Cable.Comcast.com Wed May 2 10:48:38 2012 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Wed, 2 May 2012 14:48:38 +0000 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> Message-ID: Kevin, I think your last point is very relevant to this proposal. If organizations can obtain /24's through section 8.3 without any renumbering requirement, it seems like the goal of aggregation is greatly diminished. There is a subtle lever applied here, where it forces those who do not want to renumber through section 4.3.6.2 to the transfer market where they have to pay for that pass, but it would be interesting to hear if people think whether that should be the intended behavior. If aggregation is so important to require renumbering in section 4.3.6.2, why is it not a big deal in section 8.3 which will shortly become the more frequently used option? -Dan Alexander On 4/30/12 9:13 PM, "Kevin Blumberg" wrote: >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. >_______________________________________________ >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 Wed May 2 11:57:44 2012 From: bill at herrin.us (William Herrin) Date: Wed, 2 May 2012 11:57:44 -0400 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: References: <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> Message-ID: On 5/2/12, Alexander, Daniel wrote: > If aggregation is so important to require renumbering in section 4.3.6.2, > why is it not a big deal in section 8.3 which will shortly become the more > frequently used option? Hi Daniel, It is a big deal in 8.3 and at least some of us are still ticked at the AC for stripping it out the basic protections that were in the various discussions and proposals. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Daniel_Alexander at Cable.Comcast.com Wed May 2 12:07:44 2012 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Wed, 2 May 2012 16:07:44 +0000 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: Message-ID: Thank you for the clarification Bill. Some of the reasoning behind 167 was simply a synchronization between sections 4.3.6.2 and 8.3. If you feel the synchronization is in the wrong direction, it is a valid reason to consider holding the line with the difference. Thanks, -Dan On 5/2/12 11:57 AM, "William Herrin" wrote: >On 5/2/12, Alexander, Daniel wrote: >> If aggregation is so important to require renumbering in section >>4.3.6.2, >> why is it not a big deal in section 8.3 which will shortly become the >>more >> frequently used option? > >Hi Daniel, > >It is a big deal in 8.3 and at least some of us are still ticked at >the AC for stripping it out the basic protections that were in the >various discussions and proposals. > >Regards, >Bill Herrin > > >-- >William D. Herrin ................ herrin at dirtside.com bill at herrin.us >3005 Crane Dr. ...................... Web: >Falls Church, VA 22042-3004 From lar at mwtcorp.net Wed May 2 12:06:29 2012 From: lar at mwtcorp.net (Larry Ash) Date: Wed, 02 May 2012 10:06:29 -0600 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: References: <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> Message-ID: On Wed, 2 May 2012 11:57:44 -0400 William Herrin wrote: > On 5/2/12, Alexander, Daniel wrote: >> If aggregation is so important to require renumbering in section 4.3.6.2, >> why is it not a big deal in section 8.3 which will shortly become the more >> frequently used option? > > Hi Daniel, > > It is a big deal in 8.3 and at least some of us are still ticked at > the AC for stripping it out the basic protections that were in the > various discussions and proposals. Hear Hear! +1 > > 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. Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From tedm at ipinc.net Wed May 2 12:49:59 2012 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 02 May 2012 09:49:59 -0700 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: References: Message-ID: <4FA165B7.8040900@ipinc.net> Note the language in 8.3: "...can demonstrate the need for such resources in the amount which they can justify under current ARIN policies..." -----------------^^^^^^^^^^^^^^^^^^^^^^^^^^^ Current ARIN policies are that small allocations (/24s, /23s) be aggregated. Section 8.3 thus does not give a "free pass" to transferring bodies to subvert the aggregation policy - depending on your point of view, that is. The real problem is that (in my humble opinion) the AC has moved in the direction in recent years of approving these very broad, generalized changes to the NRPM rather than specific changes. Take for example section 3.6.1. The AC only permitted that to be passed AFTER we inserted the clause "...If ARIN staff deems a POC to be..." because that effectively gives ARIN staff the ability to short-circuit the entire section - they can decide that an obviously unreachable POC (obvious to everyone else, that is) is in fact reachable - and thus excluded from requirements of 3.6.1 The AC seems to find specific restrictions in the NRPM to be a hindrance to the operation of the RIR and so constantly pushes for more generalized language that contains trap-doors that allow the Hostmaster more and more discretion to pretty much ignore the NRPM when they feel like it. I don't know when they started this policy but it's pretty obvious when you look at the NRPM history - the sections which are clear and specific - like 4.3.6.2 - are older. The Hostmaster has less leeway there to make exceptions. But newer sections, like 8.3, are very wishy-washy and lack specificity and are quite subject to a variety of interpretations, many of which are contrary to what the community wanted when the section was put in. Those sections allow the Hostmaster a free hand to say this and that about whatever they want. In essence, power is being transferred from the community to the RIR. Things like the "emergency action" which got transfers into the NRPM in the first place, show who holds the real power. I suppose the answer is "run for AC and then change it if you get on there" but it appears to be a requirement of being on the AC to get a frontal lobotomy. ;-) Seriously, it seems that once people get on there they abandon the very principles of doing what is right, for the principles of doing what "works" or what "pisses off the fewest number of people" even if it's a band-aid that will cause obvious problems later. Kicking the can down the IPv4 road seems to be in style these days. Section 8.3 is shameful, and I cannot believe that the ARIN community would have written much less supported something so wishy-washy and subjective 10 years ago. A decade ago the RIR actually cared about good stewardship of IPv4 - today the feeling seems to be to allow IPv4 to get so messed up that it's unusable and that will force people to switch to IPv6. Ted On 5/2/2012 7:48 AM, Alexander, Daniel wrote: > Kevin, > > I think your last point is very relevant to this proposal. If > organizations can obtain /24's through section 8.3 without any renumbering > requirement, it seems like the goal of aggregation is greatly diminished. > There is a subtle lever applied here, where it forces those who do not > want to renumber through section 4.3.6.2 to the transfer market where they > have to pay for that pass, but it would be interesting to hear if people > think whether that should be the intended behavior. > > If aggregation is so important to require renumbering in section 4.3.6.2, > why is it not a big deal in section 8.3 which will shortly become the more > frequently used option? > > -Dan Alexander > > > On 4/30/12 9:13 PM, "Kevin Blumberg" wrote: > >> 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. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Wed May 2 13:43:18 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 2 May 2012 10:43:18 -0700 Subject: [arin-ppml] IPv6 Renumbering (Was: Re: ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers) In-Reply-To: References: Message-ID: Correct me if I'm wrong, but, isn't prop 167 aimed at IPv4? I don't believe there are any renumbering requirements in ARIN policy for IPv6. Owen On May 1, 2012, at 10:39 AM, Scott Leibrand wrote: > On Tue, May 1, 2012 at 9:49 AM, Joe Maimon wrote: > > I suspect it would be more significant to note which of us have not interacted with a significant renumbering event, rather than the opposite. > > The less often people renumber the more painful it is likely to be when they do so, not just for themselves, but for everyone else who may be faced with it at one point. > > This is due to the pain being wholly self inflicted, in that dependencies are formed and grown under the assumption of address longevity. > > To a much larger extent than normally practiced, varying amounts of this self inflicted pain is avoidable with forethought, planning, and self discipline. > > Attributes which are usually far less prevalent then they should be. > > Attributes which are not recognized as valuable without the understanding and experience of renumbering, and that it is neither always predictable nor avoidable. > > The greater the emphasis placed on preparing for renumbering as opposed to avoiding it, the more likely that workable technology that properly abstracts the task is developed and deployed. > > How renumber-able are the typical IPv6 deployments? > > With regard to IPv6, you might find the active IETF IPv6 Site Renumbering working group to be of interest: https://datatracker.ietf.org/wg/6renum/ > > -Scott > _______________________________________________ > 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 owen at delong.com Wed May 2 14:15:08 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 2 May 2012 11:15:08 -0700 Subject: [arin-ppml] ARIN-prop-168 Promote 4byte ASN Usage In-Reply-To: <4FA02C10.7060408@arin.net> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FA02C10.7060408@arin.net> Message-ID: <513304D5-E827-4F53-AD4A-2D0EB9E9777F@delong.com> I could support this policy with the following changes: 5.2.2 Remove "AS Number or" from the first sentence. 5.2.3 I don't understand what causes are being rectified, so, this entire paragraph does not yet make sense to me. I would appreciate clarification from the author. 5.2.4 I would prefer to see a longer period. 5.2.5 I don't really see a purpose to this clause. I would delete it. 5.2.6 is a no-op. It should be removed. 5.2.7 should also be removed. The policy can be retired by a proposal that achieves community consensus. There is no need for an auto- expiry process that is optional at the discretion of staff. I don't believe this policy will do anything to achieve the objective stated in the title, however, perhaps that is because I cannot decipher 5.2.3. If the author manages to sufficiently clarify 5.2.3 and/or modify the policy such that it would demonstrably achieve the titled objective, I would support that objective. Otherwise, it just looks like an attempt to back-door ASN transfers which I oppose. Owen On May 1, 2012, at 11:31 AM, ARIN wrote: > ARIN-prop-168 Promote 4byte ASN Usage > > 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-168 Promote 4byte ASN Usage > > Proposal Originator: Joe Maimon > > Proposal Version: 1.0 > > Date: 1 May 2012 > > Proposal type: Modify > > Policy term: Temporary > > Policy statement: > > Add section 5.2 > > 5.2 Guidelines > > ARIN will issue AS Numbers under the following guidelines. > > 5.2.1 Unused > > ARIN will attempt to assign to the organization an AS Number which has > neither been previously assigned nor used, as available. > > 5.2.2 Requests > > An organization may request from ARIN either a specific AS Number or > type of AS Number, if available to ARIN. The organization must provide > to ARIN's satisfaction technical justification for its request. ARIN may > review the data directly with all involved parties. > > 5.2.3 Rectification > > ARIN, with suitable privacy considerations in place, may reuse the > provided technical documentation in such public forums as it deems > necessary to promote the rectification of the documented causes. > > 5.2.4 Restrictions > > Assignments received via 5.2.2 requests are additionally restricted from > being transferred for a period of 24 months post assignment. > > 5.2.5 Release > > An organization can exchange the 5.2.2 number for a 5.2.1 number, after > which time the restriction on transferring the assignment will be released. > > 5.2.6 Publication > > This section provides neither requirement nor recommendation that ARIN > publicize its available AS Numbers. > > 5.2.7 Expiration > > ARIN may retire section 5.2 anytime after a period of 24 calendar months > without any completed 5.2.2 requests. > > Rationale: > > Unless otherwise requested, providing an ASN with no baggage or history > should be preferential to both the organization and to ARIN. > > The restrictions and clauses regarding technical justification are > designed for the promotion of 4byte ASN uptake and preservation of 2byte > ASN's for those who truly need them. Additionally, this may help to > assist in resolving apparently pervasive obstacles in the ARIN region to > using 4byte ASN's. > > Further, if an organization does have a valid technical justification > for a specific AS Number that is available, for example, when a network > was built with an ASN that was subsequently reclaimed due to accidental > negligence or other similar cases, there is little benefit to ARIN > refusing to provide the organization what it can show it needs. > > Should this policy become a relic (we hope), ARIN is expressly > authorized to excise 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. From info at arin.net Wed May 2 15:00:12 2012 From: info at arin.net (ARIN) Date: Wed, 02 May 2012 15:00:12 -0400 Subject: [arin-ppml] ARIN-prop-169 Cleanup IPv6 section 6.5.7 In-Reply-To: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> Message-ID: <4FA1843C.2070803@arin.net> ARIN-prop-169 Cleanup IPv6 section 6.5.7 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-169 Cleanup IPv6 section 6.5.7 Proposal Originator: Andrew Dul Proposal Version: 1 Date: 2 May 2012 Proposal type: modify Policy term: permanent Policy statement: Remove paragraph starting with "Organizations that received /35 IPv6 allocations under the previous" in section 6.5.7 of NRPM. Rationale: Problem Statement: Cleanup existing NRPM policy to make IPv6 policy clearer and more concise. Section 6.5.7 was modified by policy 2011-3 by adding the paragraph "LIRs which received an allocation under previous policies which is smaller than what they are entitled to under this policy may receive a new initial allocation under this policy. If possible, ARIN will expand their existing allocation." to this section. The new paragraph that was added is believed to be inclusive of the original paragraph's intent, thus making the current 1st paragraph of this section redundant. The second paragraph is believed to be inclusive of allocations that would be granted under the first paragraph. Timetable for implementation: As soon as practical From jmaimon at chl.com Wed May 2 15:20:12 2012 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 02 May 2012 15:20:12 -0400 Subject: [arin-ppml] ARIN-prop-168 Promote 4byte ASN Usage In-Reply-To: <513304D5-E827-4F53-AD4A-2D0EB9E9777F@delong.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FA02C10.7060408@arin.net> <513304D5-E827-4F53-AD4A-2D0EB9E9777F@delong.com> Message-ID: <4FA188EC.6030406@chl.com> Hey Owen, Owen DeLong wrote: > I could support this policy with the following changes: > > 5.2.2 Remove "AS Number or" from the first sentence. To clarify, you are objecting to language that would allow an org to request a specific AS from ARIN, assuming it knows it is available. Yes, this allows an org the chance to try and get an aesthetically or otherwise pleasing ASN they may not have otherwise. Whats the harm in that? But if dropping it is all it would take to win public support, its an easy loss. > > 5.2.3 I don't understand what causes are being rectified, so, this entire > paragraph does not yet make sense to me. I would appreciate clarification > from the author. In the simplest case, it would allow ARIN to explain to the room at some future ppm why 4byte ASN utilization is so low, put the pages in the wiki, document and present to the community other potentially valid concerns, produce material that can be useful to parties involved in similar situations, etc... Yes, this may allow ARIN to operate a 4byte wall of shame. > > 5.2.4 I would prefer to see a longer period. Anything from 12-48 months is fine with me, personally. However, consider that this restriction as written applies to both 8.2 and 8.3 transfers. > > 5.2.5 I don't really see a purpose to this clause. I would delete it. An organization that wants to transfer an ASN, but cannot because 5.2.4 applies to it, has the option to exchange the ASN for a 5.2.1 which has no such restriction, should they wish to avail themselves of it. I suppose some grace time for renumbering may not be a bad idea. > > 5.2.6 is a no-op. It should be removed. Its there to prevent ARIN staff from concluding that in order to implement 5.2.2 they need to publish an entire list of available ASNs, which they may reasonably do so without making it explicitly non-dependent. > > 5.2.7 should also be removed. The policy can be retired by a proposal that > achieves community consensus. There is no need for an auto- > expiry process that is optional at the discretion of staff. How much effort is expended on policy cleanup for unused sections? Without active interest, I dont expect such a proposal to ever show up, unless the ARIN staff solicits one for disuse. So in that case, let them just remove it at that point. Also not a pivotal aspect of the proposal. > > I don't believe this policy will do anything to achieve the objective stated > in the title, however, perhaps that is because I cannot decipher 5.2.3. > If the author manages to sufficiently clarify 5.2.3 and/or modify the policy > such that it would demonstrably achieve the titled objective, I would > support that objective. > > Otherwise, it just looks like an attempt to back-door ASN transfers which > I oppose. > > > Owen The proposal was written with the expectation that directed ASN transfers are likely to be allowed via policy sometime soon, it is not intended to allow or disallow them on its own, except to add this additional restriction, applicable ONLY inasmuch as an ASN transfer is allowed, either via 8.2 currently or as 8.3 might be amended. Best, Joe From cgrundemann at gmail.com Wed May 2 15:18:44 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 2 May 2012 13:18:44 -0600 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: References: <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> Message-ID: On Wed, May 2, 2012 at 9:57 AM, William Herrin wrote: > On 5/2/12, Alexander, Daniel wrote: >> If aggregation is so important to require renumbering in section 4.3.6.2, >> why is it not a big deal in section 8.3 which will shortly become the more >> frequently used option? > > Hi Daniel, > > It is a big deal in 8.3 and at least some of us are still ticked at > the AC for stripping it out the basic protections that were in the > various discussions and proposals. While I disagree with the blame being laid solely on the AC (we generally do what the majority of the community asks us to), I do agree that this is an equal issue in 8.3 and point out (again) that this is one of the unintended (or at least unannounced) effects of 2011-11. Before 2011-11, all of the new member (slow-start) policies applied equally to allocations and specified transfers. Only with the adoption of 2011-11 were those protections removed for 8.3 transfers. I certainly do not remember anyone lobbying for de-aggregation in transfers, that is simply the way things have turned out. $.02 ~Chris > > 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. -- @ChrisGrundemann http://chrisgrundemann.com From Daniel_Alexander at Cable.Comcast.com Wed May 2 15:32:56 2012 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Wed, 2 May 2012 19:32:56 +0000 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <4F9EC985.1030503@arin.net> Message-ID: I will probably get flamed for this one, but I wanted to try and explain why I voted against this proposal during the AC meeting. If I borrow some wording from the proposed PDP, when the AC has to determine consensus we have to determine whether the proposed change has substantially more support than opposition in the community active in the discussion. (56 PPML posts: 6 for, 3 against)(106 people in the room of the Public Policy Meeting: 27 for, 11 against) We also have to consider that the specific concerns expressed have been considered. This last part is one of the reasons I voted against this proposal. I think that 2012-3 breaks new ground in that it has no technical need as a foundation. This proposal allows a part of the community to do something they want to do, rather than technically need to do. Bear with me here before this splinters into days of argument. To be clear, I am not suggesting this should not be allowed, rather question what is the appropriate level of dissent or support for such a change. Some policy debates have to move past the dissenting opinions because the implications may outweigh the result of not making a change. If, however there are no technical downside, then similar consideration has to be given to both opinions of the community. One cannot dismiss the personal opinions of those who object to the change when those in dissent are supposed to accept the opinions of those who want it for no other reason. We need a serious debate over what is the appropriate level of support for a non-technical proposal. Because of this, I do not feel that appropriate consensus has been reached and this proposal warrants further discussion. Not only for the merits of the proposal itself but for the implications that this change has on how we are referred to as the "Internet Technical Community". Dan Alexander AC Member On 4/30/12 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. From farmer at umn.edu Wed May 2 15:56:19 2012 From: farmer at umn.edu (David Farmer) Date: Wed, 02 May 2012 14:56:19 -0500 Subject: [arin-ppml] ARIN-prop-169 Cleanup IPv6 section 6.5.7 In-Reply-To: <4FA1843C.2070803@arin.net> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FA1843C.2070803@arin.net> Message-ID: <4FA19163.1070006@umn.edu> I support this proposal, and I believe it would simplify the text of 6.5.7. As one of the shepherds for ARIN-2011-3, I'd like to provide some context; ARIN-2011-3 originally had requirement for return that was removed in the last-call process. With a return requirement it made sense to keep the original text allowing /35 recipients to move to /32 without return. I honestly don't recall if it was simply an oversight that we didn't change the text to replace 6.5.7 or if we did it that way to minimize the changes made in last call. However, the modified ARIN-2011-3 called for the text to be added to the section and not replace the section, so to be clear ARIN Staff implemented ARIN-2011-3 as instructed by the policy. Thanks Andrew. On 5/2/12 14:00 CDT, ARIN wrote: > ARIN-prop-169 Cleanup IPv6 section 6.5.7 > > Proposal Originator: Andrew Dul > > Proposal Version: 1 > > Date: 2 May 2012 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Remove paragraph starting with "Organizations that received /35 IPv6 > allocations under the previous" in section 6.5.7 of NRPM. > > Rationale: > > Problem Statement: Cleanup existing NRPM policy to make IPv6 policy > clearer and more concise. > > Section 6.5.7 was modified by policy 2011-3 by adding the paragraph > > "LIRs which received an allocation under previous policies which is > smaller than what they are entitled to under this policy may receive a > new initial allocation under this policy. If possible, ARIN will expand > their existing allocation." > > to this section. > > The new paragraph that was added is believed to be inclusive of the > original paragraph's intent, thus making the current 1st paragraph of > this section redundant. > > The second paragraph is believed to be inclusive of allocations that > would be granted under the first paragraph. > > Timetable for implementation: As soon as practical -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From dburk at burkov.aha.ru Wed May 2 19:44:48 2012 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Thu, 3 May 2012 03:44:48 +0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <68767A02-BBC6-43D2-B62F-947829343038@arin.net> 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> Message-ID: John, first of all - I speak just in personal I worry not about CALEA reqs - which is your (US job - hope you remember it is not for all your region) - we have compareablae - named SORM. It is not about it - the issue for me - should be RIR responsible for end user assignments data? Dima PS IMHO it could be the biggist mistake in our policies or actions sorry - i am on vacations and can't reply in time On Apr 30, 2012, at 9:04 PM, John Curran wrote: > 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 paul at redbarn.org Wed May 2 21:08:08 2012 From: paul at redbarn.org (paul vixie) Date: Thu, 03 May 2012 01:08:08 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> Message-ID: <4FA1DA78.4090401@redbarn.org> On 5/2/2012 11:44 PM, Dmitry Burkov wrote: > ... It is not about it - the issue for me - should be RIR responsible for end user assignments data? > > Dima > PS > IMHO it could be the biggist mistake in our policies or actions someone has to be. we're not going to grow the internet economy another order of magnitude if we continue to reduce the accountability of the people and companies who can reserve unique resources. 'whois' or something like it has to be made to work, and i can't think of where else this responsibility could rest (for internet numbering resources) than in the RIR system. From dburk at burkov.aha.ru Wed May 2 21:15:12 2012 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Thu, 3 May 2012 05:15:12 +0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <4FA1DA78.4090401@redbarn.org> 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> Message-ID: <50075C07-6D84-4753-83E3-DFDE52A229E6@burkov.aha.ru> Paul. imho - the data should distributed - yes - it could be different for arin - as you can easily can forget that you are responsible not only for US Dima ps we should solve this issue any way - but not this way superconcentration of power is dangerous for rirs On May 3, 2012, at 5:08 AM, paul vixie wrote: > On 5/2/2012 11:44 PM, Dmitry Burkov wrote: >> ... It is not about it - the issue for me - should be RIR responsible for end user assignments data? >> >> Dima >> PS >> IMHO it could be the biggist mistake in our policies or actions > > someone has to be. we're not going to grow the internet economy another > order of magnitude if we continue to reduce the accountability of the > people and companies who can reserve unique resources. 'whois' or > something like it has to be made to work, and i can't think of where > else this responsibility could rest (for internet numbering resources) > than in the RIR system. > _______________________________________________ > 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 paul at redbarn.org Wed May 2 21:28:03 2012 From: paul at redbarn.org (paul vixie) Date: Thu, 03 May 2012 01:28:03 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <50075C07-6D84-4753-83E3-DFDE52A229E6@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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <50075C07-6D84-4753-83E3-DFDE52A229E6@burkov.aha.ru> Message-ID: <4FA1DF23.1000807@redbarn.org> On 5/3/2012 1:15 AM, Dmitry Burkov wrote: > Paul. > imho - the data should distributed - yes - it could be different for arin - as you > can easily can forget that you are responsible not only for US i have not made the mistake of forgetting non-us countries. rather, i am thinking in terms of the health of the internet economy, for the good of the world. we, the citizens of the internet, need accountability for those people and companies who are allowed to reserve unique internet resources such as numbers. and in case there's any question of russian/english word choices, let me say that i don't want such data to be "distributed" other than to trustworthy parties under nondisclosure and other restricted terms. if we allow for "distribution" in the sense of anyone and everyone being able to possess unrestricted copies of the aggregate of all registration information, then that would encourage registrants to hide, either from spammers, from criminals, and so on. what i want for registration data is accuracy and fair/reasonable access to specific information at need. > Dima > ps > we should solve this issue any way - but not this way > superconcentration of power is dangerous for rirs as a child of the cold war, i know well the dangers of superconcentrated power. however, i am not willing to trade away accountability to get avoidance of concentration of power. instead i propose that the community formulate reasonable rules that balance the rights of registrants with the rights of the rest of the community, and that the community maintain vigilant control of the instruments they create (whether RIR's or governments or armies or police forces) to prevent abuses of any necessarily concentrated power. -- "But I'm not done complaining." --Dagon, 2012 From owen at delong.com Wed May 2 21:37:17 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 2 May 2012 18:37:17 -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> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> Message-ID: <39BDF3B7-0159-4596-BEAF-A7A336645D63@delong.com> On Apr 30, 2012, at 6:58 PM, Jimmy Hess wrote: > 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. > That simply isn't true. The fact that so few have applied for increased space in such a sea of initial applications appears to prove exactly what Kevin stated. I know of a few cases where entities have chosen to create "subordinate" organizations and apply separately for additional multihomed space instead of renumbering in order to work around the limitations in this policy. I would not call what they have done fraudulent since they went to the trouble of creating the actual additional organizations, but, I would say that if the overhead of creating an additional organization is less onerous than the renumbering inflicted by the policy, it's a pretty clear demonstration that the renumbering clause in the policy is problematic. > 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? > I don't believe so, but, this hasn't been done for any other size of assignment, either. > There is an alternative explanation: perhaps they did not need more > IP addresses, > or they didn't need them very much. I know that there are at least some cases where that is not the case. > > 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. > Sure, and I'm sure that's true for SOME organizations, but, definitely not all. > > 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. Yes, there is indication that the policy erred. Staff provided an indication from their perspective in the policy experience report. I know of cases where it has been problematic for organizations personally. I suspect Kevin does as well, but I will let him speak for himself. > > 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. If I recall correctly, the renumbering requirement of which we speak is applied to small multihoming end users and not ISPs, so, I don't think your argument here holds water. Yep... Just verified it in NRPM. The requirement in question is contained in 4.3.2.2 which is part of the 4.3 end user policy. It is not part of the 4.2 ISP policy. In fact, the ISP policy still requires justification of a /22 to start, even for small multihomed ISPs. I think there is an exception for the Caribbean, but, this change would not affect that in any case. Owen From jcurran at arin.net Wed May 2 21:45:41 2012 From: jcurran at arin.net (John Curran) Date: Thu, 3 May 2012 01:45:41 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> Message-ID: On May 2, 2012, at 7:44 PM, Dmitry Burkov wrote: > John, > first of all - I speak just in personal Understood. > I worry not about CALEA reqs - which is your (US job - hope you remember it is not for all your region) - we have > compareablae - named SORM. Actually, CALEA is applicable to service providers in the US, not ARIN as the Internet number registry. > It is not about it - the issue for me - should be RIR responsible for end user assignments data? I do not believe that an RIR should be responsible for maintaining end-user assignment data, but that is not what is being discussed. The question is whether an RIR might have to ask about end-user assignment data in the process of verifying utilization of an address block. At present, there is no policy in this region which precludes ARIN from requesting that information if it is felt to be needed in the process of verifying utilization, and ARIN does in fact ask for this information as necessary. FYI, /John John Curran President and CEO ARIN From owen at delong.com Wed May 2 21:43:24 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 2 May 2012 18:43:24 -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 7:22 PM, William Herrin wrote: > 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. Actually, APNIC is not cruising without a free pool even now. They are cruising with a rationed free pool which is limited to a single /22 per ORG ever. > > >> 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. > The number of /24s remaining in the ARIN free pool is dwarfed by the number of /24s already in the routing table. ARIN has ~6.8 /8s remaining in all of its freepool space (reservations included if I understand correctly) which if fully expanded to /24s would represent 447,007 /24s. Given that most of the ARIN run rate is in larger blocks and that /22s even at 1:1 allocation rates would consume 3/4 of that space, I can't see how you would make a case for the impact of this policy having any potential beyond 111,752 additional routing table entries. OTOH, anyone can now buy as many /24s on the transfer market as they can justify, even one /24 at a time (we got rid of the single aggregate provision in the transfer policy), so, if you want to worry about nibbling away at the routing table, let's focus on the potential for problems there, rather than in this piddling little policy. Owen From frnkblk at iname.com Wed May 2 22:11:09 2012 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 2 May 2012 21:11:09 -0500 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: <00ca01cd28d2$0156ee90$0404cbb0$@iname.com> I second Bill's thoughts here -- let them keep the first /24 and avoid the re-numbering pain, but if they really have a justification for a /22 or shorter, will there really be that many /24's from that situation that pollute the RIB? The first /24 is likely more painful to renumber than any subsequent netblock received. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Monday, April 30, 2012 9:22 PM To: Bill Darte Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers 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 _______________________________________________ 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 dburk at burkov.aha.ru Wed May 2 22:29:20 2012 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Thu, 3 May 2012 06:29:20 +0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> Message-ID: <813F732B-F29E-4A75-A8FE-B3A3A047E23C@burkov.aha.ru> On May 3, 2012, at 5:45 AM, John Curran wrote: > On May 2, 2012, at 7:44 PM, Dmitry Burkov wrote: > >> John, >> first of all - I speak just in personal > > Understood. > >> I worry not about CALEA reqs - which is your (US job - hope you remember it is not for all your region) - we have >> compareablae - named SORM. > > Actually, CALEA is applicable to service providers in > the US, not ARIN as the Internet number registry. I hope as SORM for Russia > >> It is not about it - the issue for me - should be RIR responsible for end user assignments data? > > I do not believe that an RIR should be responsible for > maintaining end-user assignment data, but that is not > what is being discussed. > What I mean > The question is whether an RIR might have to ask about > end-user assignment data in the process of verifying > utilization of an address block. At present, there > is no policy in this region which precludes ARIN from > requesting that information if it is felt to be needed > in the process of verifying utilization, and ARIN does > in fact ask for this information as necessary. I worry as I have got impression that you LEAs already expected that you can simplify their jobs... > > FYI, > /John > > John Curran > President and CEO > ARIN > From dburk at burkov.aha.ru Wed May 2 22:38:32 2012 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Thu, 3 May 2012 06:38:32 +0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <4FA1DF23.1000807@redbarn.org> 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <50075C07-6D84-4753-83E3-DFDE52A229E6@burkov.aha.ru> <4FA1DF23.1000807@redbarn.org> Message-ID: On May 3, 2012, at 5:28 AM, paul vixie wrote: > On 5/3/2012 1:15 AM, Dmitry Burkov wrote: >> Paul. >> imho - the data should distributed - yes - it could be different for arin - as you >> can easily can forget that you are responsible not only for US > > i have not made the mistake of forgetting non-us countries. rather, i am > thinking in terms of the health of the internet economy, for the good of > the world. we, the citizens of the internet, need accountability for > those people and companies who are allowed to reserve unique internet > resources such as numbers. and in case there's any question of > russian/english word choices, let me say that i don't want such data to > be "distributed" other than to trustworthy parties under nondisclosure > and other restricted terms. if we allow for "distribution" in the sense > of anyone and everyone being able to possess unrestricted copies of the > aggregate of all registration information, then that would encourage > registrants to hide, either from spammers, from criminals, and so on. absolutely agree > > what i want for registration data is accuracy and fair/reasonable access > to specific information at need. no matter - I want to add only one - as community decided. Even today we have all necessary info to identify anyone on the net = the isuue is only should be concentarated or not? > >> Dima >> ps >> we should solve this issue any way - but not this way >> superconcentration of power is dangerous for rirs > > as a child of the cold war, i know well the dangers of superconcentrated > power. however, i am not willing to trade away accountability to get > avoidance of concentration of power. instead i propose that the > community formulate reasonable rules that balance the rights of > registrants with the rights of the rest of the community, and that the > community maintain vigilant control of the instruments they create > (whether RIR's or governments or armies or police forces) to prevent > abuses of any necessarily concentrated power. it is now more the issue of cost of operations and legal risks... sorry - but I think that it should not be rirs responsibility as we have no direct en user contracts > > -- > "But I'm not done complaining." --Dagon, 2012 > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Wed May 2 22:43:50 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 2 May 2012 19:43:50 -0700 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <5EADDA72-6338-4CAF-BF4E-F8D2A8C9D063@netconsonance.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <4FA01422.6030402@chl.com> <5EADDA72-6338-4CAF-BF4E-F8D2A8C9D063@netconsonance.com> Message-ID: On May 1, 2012, at 9:39 PM, Jo Rhett wrote: > On May 1, 2012, at 3:35 PM, Bill Darte wrote: >> Are you for, or against the proposal? > > I'm of deeply mixed opinion. I definitely understand the routing table slots issue. But I suspect it has less meaning now than it did before, due to everyone having to get much bigger tables in the last few years anyway. And there simply won't be *that* many /24s that acquire another /24. Before I consider that a threat, I'd like to see someone do the math real quick on how many /24s are there, and if every one of them got another /24 (if that is possible in the current free pool) what the table growth would be. > > I absolutely don't feel that "pain of renumbering" is now, nor should ever dictate policy. I don't think we should renumber without reason, but hell we all re-arrange when we move to a bigger house ;-) > Indeed, I think that moving to a bigger house is a much better analogy for the effort involved than a trip to the grocery store. Gorcery store: Unpleasant and I try to stall on it as long as I can, but, seems to happen at least once every other week anyway. Moving: Always hated it. Always thought it was a pain. Moved about once a year from 1984-1993 and hated it each and every time. Haven't moved since 1993 and fully expect to be in my current home until I leave feet first. In the grand scheme of housing, I'd say my current home is /24-ish (1300 sq. feet). More space would be useful, but, I don't really need it and it isn't worth the effort entailed in moving. Would I buy the house next door if it became available and expand into it? Maybe if the price was right and I felt I needed the additional space. Since prefix next door and some other prefix are roughly equivalent except for the table implications, the equivalent of buying an additional house seems to make more sense to me than buying a larger house and moving everything into the one new house. Owen From mysidia at gmail.com Thu May 3 00:11:43 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 2 May 2012 23:11:43 -0500 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <8EB5E74F-9E9C-45BB-8608-8052E45610A4@netconsonance.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <8EB5E74F-9E9C-45BB-8608-8052E45610A4@netconsonance.com> Message-ID: 'On 5/1/12, Jo Rhett wrote: > On May 1, 2012, at 9:52 AM, William Herrin wrote: >> First there's DNS pinning. Because of DNS pinning, web browsers won't >> follow your new IP address when the DNS TTL runs out. In some cases, What? Web servers are a snap to renumber; DNS pinning is not an issue. Recursive DNS servers are harder to renumber, because the IP addresses are often configured directly by hand on end user systems, which means that a per-system cost must be incurred if this activity cannot be automated, IT staff time must be consumed to reconfigure DNS server settings on each network device, costs are incurred to the END user of the ISP, and they may be annoyed that their ISP's renumbering requires that they expend man hours to update configurations of their equipment. Unfortunately, the DNS RFCs don't provide a method for a recursive DNS server to tell the end user client system to permanently reconfigure the IP address of the server queried to the new one (without end user intervention). A standard method of renumbering is to transition services. Web servers get configured with both old and new IP addresses. The DNS records are updated, and both new and old IP addresses are valid until renumbering is completed. DNS pinning beyond a normal DNS TTL period would be an anomaly, and is likely a unique issue to be addressed by the end user (by rebooting their equipment). But beyond a few days, its an imaginary problem. Note that the ARIN /24 policy allows a 12 month transition period, which is plenty of time to have DNS changes to a webserver hostname take effect. Browser windows don't get left open for 3 months. Even if the DNS pinning _DID_ happen to be broken in some version of a major browser in use by users; that can be addressed by the amount of time that the renumbering is performed over. It is not as if the /24 assignment policy requirement is that the ISP complete their renumbering within 30 days. -- -JH From kevinb at thewire.ca Thu May 3 00:48:08 2012 From: kevinb at thewire.ca (Kevin Blumberg) Date: Thu, 3 May 2012 04:48:08 +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> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <8EB5E74F-9E9C-45BB-8608-8052E45610A4@netconsonance.com> Message-ID: <7E7773B523E82C478734E793E58F69E769523C9A@SBS2011.thewireinc.local> Jimmy, In practice your description of renumbering is completely valid. I have found that there are always edge cases that complicate the situation. I had to renumber a /23 a couple years back that was supporting 1000 domains for webhosting. I used a similar method you described below and that handled 85 percent of the customers. Then the edge cases started cropping up, domains that we were not authoritative on, and the customer had hard coded the A records for the old IP netblock. Customers that had hard coded the IP inside of scripts and firewalls. We spent countless hours contacting the customers to complete the work and every time we had to tip toe because we were inconveniencing them. I consider the initial decision to renumber out of PA space and get your first PI space hard enough. It is a careful balance of having freedom and flexibility with the work to renumber. To require an organization to do it over and over again as they grow is wrong. 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: Thursday, May 03, 2012 12:12 AM > To: Jo Rhett > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-167 Removal of Renumbering > Requirement for Small Multihomers > > 'On 5/1/12, Jo Rhett wrote: > > On May 1, 2012, at 9:52 AM, William Herrin wrote: > >> First there's DNS pinning. Because of DNS pinning, web browsers won't > >> follow your new IP address when the DNS TTL runs out. In some cases, > > What? Web servers are a snap to renumber; DNS pinning is not an > issue. Recursive DNS servers are harder to renumber, because the > IP addresses are often configured directly by hand on end user systems, > which means that a per-system cost must be incurred if this activity cannot > be automated, IT staff time must be consumed to > reconfigure DNS server settings on each network device, costs are > incurred to the END user of the ISP, and they may be annoyed that their > ISP's renumbering requires that they expend man hours to update > configurations of their equipment. > > Unfortunately, the DNS RFCs don't provide a method for a recursive > DNS server to tell the end user client system to permanently > reconfigure the IP address of the server queried to the new one (without > end user intervention). > > > > A standard method of renumbering is to transition services. > Web servers get configured with both old and new IP addresses. > The DNS records are updated, and both new and old IP addresses are valid > until renumbering is completed. > > DNS pinning beyond a normal DNS TTL period would be an anomaly, and > is likely a unique issue to be addressed by the end user (by > rebooting their equipment). > > But beyond a few days, its an imaginary problem. > Note that the ARIN /24 policy allows a 12 month transition period, which is > plenty of time to have DNS changes to a webserver hostname take effect. > > Browser windows don't get left open for 3 months. Even if the DNS > pinning _DID_ happen to be broken in some version of a major browser > in use by users; that can be addressed by the amount of time that > the renumbering is performed over. > > It is not as if the /24 assignment policy requirement is that the ISP complete > their renumbering within 30 days. > > -- > -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 tedm at ipinc.net Thu May 3 01:06:31 2012 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 02 May 2012 22:06:31 -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> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <8EB5E74F-9E9C-45BB-8608-8052E45610A4@netconsonance.com> Message-ID: <4FA21257.80508@ipinc.net> On 5/2/2012 9:11 PM, Jimmy Hess wrote: > 'On 5/1/12, Jo Rhett wrote: >> On May 1, 2012, at 9:52 AM, William Herrin wrote: >>> First there's DNS pinning. Because of DNS pinning, web browsers won't >>> follow your new IP address when the DNS TTL runs out. In some cases, > > What? Web servers are a snap to renumber; DNS pinning is not an > issue. Recursive DNS servers are harder to renumber, because the > IP addresses are often configured directly by hand on end user > systems, That's not really a problem, though. Remember, although you are required to turn in the netblock, nothing prevents you from continuing to use that netblock internally, unless whoever gets your relinquished netblock decides to use it on something that your users want to get to. When I did renumbering of DNS servers I simply took the old netblock after turning it in and setup a small network that had just the old DNS servers on it. Those servers were configured as caching servers and forwarders to the new DNS servers. I setup new DNS servers on the new IP addresses. Users who had the old numbers hard-coded would do queries to the old server IPs which I would route internally to my small network. I did this for years and then finally when the volume of traffic had dropped enough, I started selectively blocking parts of my network from this little subnet every few weeks. I'd institute a block on Monday, and get a few calls from people complaining things didn't work, I'd tell them to renumber their DNS servers, they would do it, and life would go on. In a few cases where the users had extenuating circumstances I'd lift the block and give them 30 days or whatever. which means that a per-system cost must be incurred if > this activity cannot be automated, IT staff time must be consumed to > reconfigure DNS server settings on each network device, costs are > incurred to the END user of the ISP, and they may be annoyed that > their ISP's renumbering requires that they expend man hours to > update configurations of their equipment. > Not really true since this renumbering can be done as old equipment dies and is cycled out of service. > Unfortunately, the DNS RFCs don't provide a method for a recursive > DNS server to tell the end user client system to permanently > reconfigure the IP address of the server queried to the new one > (without end user intervention). > Captain Kirk to Saavik, Wrath of Kahn: "You have to learn why things work on a starship" You have to learn why things work in TCP/IP. Once you do you will understand how trivial this problem is to get around and why they didn't bother cluttering up DNS with something like that. > > > A standard method of renumbering is to transition services. > Web servers get configured with both old and new IP addresses. > The DNS records are updated, and both new and old IP addresses are > valid until renumbering is completed. > > DNS pinning beyond a normal DNS TTL period would be an anomaly, and > is likely a unique issue to be addressed by the end user (by > rebooting their equipment). > > But beyond a few days, its an imaginary problem. > Note that the ARIN /24 policy allows a 12 month transition period, > which is plenty of time > to have DNS changes to a webserver hostname take effect. > > Browser windows don't get left open for 3 months. Even if the DNS > pinning _DID_ happen to be broken in some version of a major browser > in use by users; that can be addressed by the amount of time that > the renumbering is performed over. > > It is not as if the /24 assignment policy requirement is that the ISP > complete their renumbering within 30 days. > Let me say that years ago Microsoft produced a DNS server that IGNORED expiration TTL's. They quickly fixed that in a service pack, but I have - once - run into a commercial entity that was using an unpatched Windows server that had this bug. Your correct this is an imaginary problem if everyone followed the standards. Unfortunately not everyone does. It is a real problem. But, it is only a real problem to people who aren't following the rules, and I don't cotton on to the idea of helping those kinds of people make their lives easier. Ted > -- > -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 tedm at ipinc.net Thu May 3 01:56:43 2012 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 02 May 2012 22:56:43 -0700 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <7E7773B523E82C478734E793E58F69E769523C9A@SBS2011.thewireinc.local> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <8EB5E74F-9E9C-45BB-8608-8052E45610A4@netconsonance.com> <7E7773B523E82C478734E793E58F69E769523C9A@SBS2011.thewireinc.local> Message-ID: <4FA21E1B.4000307@ipinc.net> On 5/2/2012 9:48 PM, Kevin Blumberg wrote: > Jimmy, > > In practice your description of renumbering is completely valid. I > have found that there are always edge cases that complicate the > situation. I had to renumber a /23 a couple years back that was > supporting 1000 domains for webhosting. I used a similar method you > described below and that handled 85 percent of the customers. Then > the edge cases started cropping up, domains that we were not > authoritative on, and the customer had hard coded the A records for > the old IP netblock. Customers that had hard coded the IP inside of > scripts and firewalls. We spent countless hours contacting the > customers to complete the work and every time we had to tip toe > because we were inconveniencing them. > > I consider the initial decision to renumber out of PA space and get > your first PI space hard enough. It is a careful balance of having > freedom and flexibility with the work to renumber. To require an > organization to do it over and over again as they grow is wrong. > It is a greater wrong to require everyone else to spend lots of money upgrading their router ram to hold larger tables just to make things easier for some people. 1000 domains may seem like a lot but that figure is nothing compared to what is on the Internet today. The balance is and always has been between the amount of work that an org has to do to connect, vs the amount of work the rest of us have to do to allow them to connect. Ted > 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: >> Thursday, May 03, 2012 12:12 AM To: Jo Rhett Cc: >> arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-167 Removal >> of Renumbering Requirement for Small Multihomers >> >> 'On 5/1/12, Jo Rhett wrote: >>> On May 1, 2012, at 9:52 AM, William Herrin wrote: >>>> First there's DNS pinning. Because of DNS pinning, web browsers >>>> won't follow your new IP address when the DNS TTL runs out. In >>>> some cases, >> >> What? Web servers are a snap to renumber; DNS pinning is not an >> issue. Recursive DNS servers are harder to renumber, because >> the IP addresses are often configured directly by hand on end user >> systems, which means that a per-system cost must be incurred if >> this activity cannot be automated, IT staff time must be consumed >> to reconfigure DNS server settings on each network device, costs >> are incurred to the END user of the ISP, and they may be annoyed >> that their ISP's renumbering requires that they expend man hours >> to update configurations of their equipment. >> >> Unfortunately, the DNS RFCs don't provide a method for a >> recursive DNS server to tell the end user client system to >> permanently reconfigure the IP address of the server queried to the >> new one (without end user intervention). >> >> >> >> A standard method of renumbering is to transition services. Web >> servers get configured with both old and new IP addresses. The DNS >> records are updated, and both new and old IP addresses are valid >> until renumbering is completed. >> >> DNS pinning beyond a normal DNS TTL period would be an anomaly, >> and is likely a unique issue to be addressed by the end user (by >> rebooting their equipment). >> >> But beyond a few days, its an imaginary problem. Note that the ARIN >> /24 policy allows a 12 month transition period, which is plenty of >> time to have DNS changes to a webserver hostname take effect. >> >> Browser windows don't get left open for 3 months. Even if the >> DNS pinning _DID_ happen to be broken in some version of a major >> browser in use by users; that can be addressed by the amount of >> time that the renumbering is performed over. >> >> It is not as if the /24 assignment policy requirement is that the >> ISP complete their renumbering within 30 days. >> >> -- -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. > _______________________________________________ PPML You are > receiving this message because you are subscribed to the ARIN Public > Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your > mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml Please contact > info at arin.net if you experience any issues. From owen at delong.com Thu May 3 01:55:55 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 2 May 2012 22:55:55 -0700 Subject: [arin-ppml] ARIN-prop-168 Promote 4byte ASN Usage In-Reply-To: <4FA188EC.6030406@chl.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FA02C10.7060408@arin.net> <513304D5-E827-4F53-AD4A-2D0EB9E9777F@delong.com> <4FA188EC.6030406@chl.com> Message-ID: On May 2, 2012, at 12:20 PM, Joe Maimon wrote: > Hey Owen, > > Owen DeLong wrote: >> I could support this policy with the following changes: >> >> 5.2.2 Remove "AS Number or" from the first sentence. > > > To clarify, you are objecting to language that would allow an org to request a specific AS from ARIN, assuming it knows it is available. > > Yes, this allows an org the chance to try and get an aesthetically or otherwise pleasing ASN they may not have otherwise. > > Whats the harm in that? > I'm generally opposed to putting ARIN in the "custom license plate" business because I think there are other better higher priorities for number resource management. > But if dropping it is all it would take to win public support, its an easy loss. > Don't know about that. Certainly dropping it is a requirement to garner my support. > >> >> 5.2.3 I don't understand what causes are being rectified, so, this entire >> paragraph does not yet make sense to me. I would appreciate clarification >> from the author. > > > In the simplest case, it would allow ARIN to explain to the room at some future ppm why 4byte ASN utilization is so low, put the pages in the wiki, document and present to the community other potentially valid concerns, produce material that can be useful to parties involved in similar situations, etc... > > Yes, this may allow ARIN to operate a 4byte wall of shame. > I have no problem with policy enabling ARIN to operate a 4-octet wall of shame. However, if that is the intent, let's have the paragraph say that. I can't even parse what it says currently. I don't think ARIN knows why 4-octet ASN utilization is so low (in the ARIN region and uniquely in the ARIN region, btw). >> >> 5.2.4 I would prefer to see a longer period. > > Anything from 12-48 months is fine with me, personally. > > However, consider that this restriction as written applies to both 8.2 and 8.3 transfers. > I would modify to remove the restriction from 8.2 transfers and set the limit at 48 months (if we're going to allow 8.3 transfers of ASNs at all which I still feel is a bad idea). >> >> 5.2.5 I don't really see a purpose to this clause. I would delete it. > > > An organization that wants to transfer an ASN, but cannot because 5.2.4 applies to it, has the option to exchange the ASN for a 5.2.1 which has no such restriction, should they wish to avail themselves of it. > > I suppose some grace time for renumbering may not be a bad idea. > Ah, but if we eliminate 5.2.3 as I suggested, that becomes inoperative. > >> >> 5.2.6 is a no-op. It should be removed. > > > Its there to prevent ARIN staff from concluding that in order to implement 5.2.2 they need to publish an entire list of available ASNs, which they may reasonably do so without making it explicitly non-dependent. > Move that statement to the rational. It's an operational concern, not a policy issue. > >> >> 5.2.7 should also be removed. The policy can be retired by a proposal that >> achieves community consensus. There is no need for an auto- >> expiry process that is optional at the discretion of staff. > > > How much effort is expended on policy cleanup for unused sections? > A fair amount, actually. I don't think that there are many, if any unused or obsolete sections currently in the NRPM and there have been several proposals which have removed them just in my tenure so far on the AC (a little more than 4 years) and many more in the decade+ that I have been active in the policy process. > Without active interest, I dont expect such a proposal to ever show up, unless the ARIN staff solicits one for disuse. So in that case, let them just remove it at that point. > In the past, we have generally eschewed sunset clauses. As such, I don't think having one in this policy is particularly more desirable than any of the past cases where the community has opted not to put one in. > Also not a pivotal aspect of the proposal. > > >> >> I don't believe this policy will do anything to achieve the objective stated >> in the title, however, perhaps that is because I cannot decipher 5.2.3. >> If the author manages to sufficiently clarify 5.2.3 and/or modify the policy >> such that it would demonstrably achieve the titled objective, I would >> support that objective. >> >> Otherwise, it just looks like an attempt to back-door ASN transfers which >> I oppose. >> >> >> Owen > > > The proposal was written with the expectation that directed ASN transfers are likely to be allowed via policy sometime soon, it is not intended to allow or disallow them on its own, except to add this additional restriction, applicable ONLY inasmuch as an ASN transfer is allowed, either via 8.2 currently or as 8.3 might be amended. > Then it should say that. The proposal for ASN transfers is (unfortunately) in last call, but, it has not been recommended to the board for adoption, let alone been adopted. Owen From owen at delong.com Thu May 3 02:03:29 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 2 May 2012 23:03:29 -0700 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: Message-ID: <7D808D95-1208-485C-8B2C-2BF4776FA057@delong.com> On May 2, 2012, at 12:32 PM, Alexander, Daniel wrote: > > I will probably get flamed for this one, but I wanted to try and explain > why I voted against this proposal during the AC meeting. > > If I borrow some wording from the proposed PDP, when the AC has to > determine consensus we have to determine whether the proposed change has > substantially more support than opposition in the community active in the > discussion. (56 PPML posts: 6 for, 3 against)(106 people in the room of > the Public Policy Meeting: 27 for, 11 against) We also have to consider > that the specific concerns expressed have been considered. This last part > is one of the reasons I voted against this proposal. > > I think that 2012-3 breaks new ground in that it has no technical need as > a foundation. This proposal allows a part of the community to do something > they want to do, rather than technically need to do. Bear with me here > before this splinters into days of argument. To be clear, I am not > suggesting this should not be allowed, rather question what is the > appropriate level of dissent or support for such a change. > +1 (Though I also oppose the policy based on my belief that it is overall harmful to ARIN's mission in that it moves us away from a resource stewardship role and towards a function more closely resembling an auction house or transaction clearing house). > Some policy debates have to move past the dissenting opinions because the > implications may outweigh the result of not making a change. If, however > there are no technical downside, then similar consideration has to be > given to both opinions of the community. One cannot dismiss the personal > opinions of those who object to the change when those in dissent are > supposed to accept the opinions of those who want it for no other reason. > We need a serious debate over what is the appropriate level of support for > a non-technical proposal. > > Because of this, I do not feel that appropriate consensus has been reached > and this proposal warrants further discussion. Not only for the merits of > the proposal itself but for the implications that this change has on how > we are referred to as the "Internet Technical Community". > +1 It also needs further discussion on whether ARIN is to remain in its role as a resource steward or whether we really want to move it towards being merely a registry/registrar as practiced in the DNS world. As I see it, paid transfers have generally be a bad thing from a resource stewardship perspective. I see that we have a growing body of exceptional cases related primarily to bankruptcies and strange ideas of perceived values of particular numbers or IPv4 numbers due to scarcity. I recognize that because of the scarcity of IPv4 numbers, overall, the community is harmed (or at least apparently harmed) more in the short term by the lack of available IPv4 resources than by the paid transfers. There is a sound technical basis in this argument and it is a genuine technical need of the community. I see no such technical need for ASNs at this time or in the immediate future. Therefore, I joined Dan in voting against this proposal and I am still in opposition to it. Owen > Dan Alexander > AC Member > > > On 4/30/12 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. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Thu May 3 02:07:00 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 2 May 2012 23:07:00 -0700 Subject: [arin-ppml] ARIN-prop-169 Cleanup IPv6 section 6.5.7 In-Reply-To: <4FA19163.1070006@umn.edu> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FA1843C.2070803@arin.net> <4FA19163.1070006@umn.edu> Message-ID: <67CC9779-48CA-4253-8B8B-B7CCF7AD3F75@delong.com> I support this proposal as well. I am the author of 2011-3 and to my recollection, failing to remove this language was purely an oversight. Owen On May 2, 2012, at 12:56 PM, David Farmer wrote: > I support this proposal, and I believe it would simplify the text of 6.5.7. > > As one of the shepherds for ARIN-2011-3, I'd like to provide some context; > > ARIN-2011-3 originally had requirement for return that was removed in the last-call process. With a return requirement it made sense to keep the original text allowing /35 recipients to move to /32 without return. I honestly don't recall if it was simply an oversight that we didn't change the text to replace 6.5.7 or if we did it that way to minimize the changes made in last call. However, the modified ARIN-2011-3 called for the text to be added to the section and not replace the section, so to be clear ARIN Staff implemented ARIN-2011-3 as instructed by the policy. > > Thanks Andrew. > > On 5/2/12 14:00 CDT, ARIN wrote: > >> ARIN-prop-169 Cleanup IPv6 section 6.5.7 >> >> Proposal Originator: Andrew Dul >> >> Proposal Version: 1 >> >> Date: 2 May 2012 >> >> Proposal type: modify >> >> Policy term: permanent >> >> Policy statement: >> >> Remove paragraph starting with "Organizations that received /35 IPv6 >> allocations under the previous" in section 6.5.7 of NRPM. >> >> Rationale: >> >> Problem Statement: Cleanup existing NRPM policy to make IPv6 policy >> clearer and more concise. >> >> Section 6.5.7 was modified by policy 2011-3 by adding the paragraph >> >> "LIRs which received an allocation under previous policies which is >> smaller than what they are entitled to under this policy may receive a >> new initial allocation under this policy. If possible, ARIN will expand >> their existing allocation." >> >> to this section. >> >> The new paragraph that was added is believed to be inclusive of the >> original paragraph's intent, thus making the current 1st paragraph of >> this section redundant. >> >> The second paragraph is believed to be inclusive of allocations that >> would be granted under the first paragraph. >> >> Timetable for implementation: As soon as practical > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Thu May 3 02:58:04 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 2 May 2012 23:58:04 -0700 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <4FA0E93E.6010507@ipinc.net> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <4FA01422.6030402@chl.com> <4FA07531.4040906@chl.com> <4FA0E93E.6010507@ipinc.net> Message-ID: <5398F743-1274-4EB0-BBE6-283A356AFE23@delong.com> > Yes it's difficult to renumber. But, the org renumbering is getting > something for their trouble - that is, they are getting more IP addresses. Many small end user orgs in the past have renumbered-and-returned just fine under 4.3.6.2 I don't see that suddenly in > year 2012 that something new and special has come along that now > makes renumbering impossible for these orgs. > Uh, no, Ted, they haven't. Please refer back to Leslie's policy experience report. > But ARIN must put a barrier up to simply request-without-renumber otherwise the end user orgs will simply not do it. The proposal is Why is that so bad? Today, an organization that needs a /20 is free to go out and purchase 16 discreet /24s and advertise all of them. We're talking about an organization that started with a /24 or a /23 expanding to a maximum of 4 /24s before the policy becomes moot anyway. In fact, the current way for an organization that has a /24 and doesn't want to renumber to get to having 2 /24s worth of space is quite simple. Entity A creates corporation B and multihomes corporation B. Entity A moves half of their need into corporation B to qualify for an ARIN /24, then moves corporation B back inside Entity A through section 8.2. > throwing the baby out with the bathwater and has no recognition for > the benefit to the community of forcing orgs to use contiguous > subnets. > But there is no baby and the bathwater appears to smell pretty foul at this point. Org's today aren't forced to use contiguous subnets. With 8.3, that's only going to get a whole lot worse going forward. Owen From owen at delong.com Thu May 3 03:12:47 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 3 May 2012 00:12:47 -0700 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <4FA21257.80508@ipinc.net> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <8EB5E74F-9E9C-45BB-8608-8052E45610A4@netconsonance.com> <4FA21257.80508@ipinc.net> Message-ID: <5D2ADFC8-5166-48E9-AE93-9B567789911E@delong.com> > > Not really true since this renumbering can be done as old equipment dies > and is cycled out of service. > Not likely in the time frame permitted by the policy being debated. > Your correct this is an imaginary problem if everyone followed the > standards. Unfortunately not everyone does. It is a real problem. > But, it is only a real problem to people who aren't following the rules, > and I don't cotton on to the idea of helping those kinds of people > make their lives easier. > While I agree with you philosophically, the reality is that there is a difference when those people are "customers" vs. when they are not. When they are "customers" you tend to have to make all kinds of accommodations for whatever they _WANT_ to do regardless of how it fits into your idea of what is right. Especially when you are a business small enough to be affected by this policy. OWen From tedm at ipinc.net Thu May 3 04:44:24 2012 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 03 May 2012 01:44:24 -0700 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <5D2ADFC8-5166-48E9-AE93-9B567789911E@delong.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <8EB5E74F-9E9C-45BB-8608-8052E45610A4@netconsonance.com> <4FA21257.80508@ipinc.net> <5D2ADFC8-5166-48E9-AE93-9B567789911E@delong.com> Message-ID: <4FA24568.4050708@ipinc.net> On 5/3/2012 12:12 AM, Owen DeLong wrote: >> >> Not really true since this renumbering can be done as old equipment dies >> and is cycled out of service. >> > > Not likely in the time frame permitted by the policy being debated. > Which is why I suggested that if you want to make a policy modification of this nature a better way would be to have the NRPM allow the hostmaster to make an exception for extenuating circumstances, and extend the deadline for return to beyond 1 year. >> Your correct this is an imaginary problem if everyone followed the >> standards. Unfortunately not everyone does. It is a real problem. >> But, it is only a real problem to people who aren't following the rules, >> and I don't cotton on to the idea of helping those kinds of people >> make their lives easier. >> > > While I agree with you philosophically, the reality is that there is a difference > when those people are "customers" vs. when they are not. > > When they are "customers" you tend to have to make all kinds of accommodations > for whatever they _WANT_ to do regardless of how it fits into your idea of what > is right. Especially when you are a business small enough to be affected by > this policy. > Except that the customers (in the example cited) really can't go anywhere else without the same - and likely more - pain. Which would you rather do as a customer: a) nothing b) change a few IP addresses in some existing scripts you have c) move all your scripts to a new ISP/hoster which will force you to do all of b) plus a bunch of extra testing. We all know customers want a. But in the real world you don't always get what you want. In that case they are going to take b) over c). And in this case these are end-user addresses, the "customer" is actually an "ARIN customer" not a network customer of an ISP which is then a "customer" of ARIN. The fact is use of the term "customer" implies purchase - but IP numbers are not property and cannot be purchased, so really your argument is misleading and not applicable. The end users affected are ARIN community members that are doing the same thing you and I are doing - "renting" the use of IP addresses from the RIR, that we do not own, and that the entire community has the authority to say what's what about them. The ARIN community must make policy that is for the good of ALL of it's community members, not just the end-user ones, it cannot simply take ONLY the concerns of the end users into account when making policy. Ted > OWen > > From tedm at ipinc.net Thu May 3 05:07:39 2012 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 03 May 2012 02:07:39 -0700 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <5398F743-1274-4EB0-BBE6-283A356AFE23@delong.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <4FA01422.6030402@chl.com> <4FA07531.4040906@chl.com> <4FA0E93E.6010507@ipinc.net> <5398F743-1274-4EB0-BBE6-283A356AFE23@delong.com> Message-ID: <4FA24ADB.2080209@ipinc.net> On 5/2/2012 11:58 PM, Owen DeLong wrote: >> Yes it's difficult to renumber. But, the org renumbering is >> getting something for their trouble - that is, they are getting >> more IP addresses. Many small end user orgs in the past have >> renumbered-and-returned just fine under 4.3.6.2 I don't see that >> suddenly in year 2012 that something new and special has come along >> that now makes renumbering impossible for these orgs. >> > > Uh, no, Ted, they haven't. Please refer back to Leslie's policy > experience report. > >> But ARIN must put a barrier up to simply request-without-renumber >> otherwise the end user orgs will simply not do it. The proposal >> is > > Why is that so bad? Today, an organization that needs a /20 is free > to go out and purchase 16 discreet /24s and advertise all of them. yeah, yeah please stop with the 8.3 gong banging. > We're talking about an organization that started with a /24 or a /23 > expanding to a maximum of 4 /24s before the policy becomes moot > anyway. I would submit that most orgs that start with a /24 either are low-to-no growth and will never really need anything beyond the /24, or they have a good enough mousetrap that people are clawing for what they have and they can easily justify jumping from a /24 to a /22 on the first go around. > In fact, the current way for an organization that has a /24 > and doesn't want to renumber to get to having 2 /24s worth of space > is quite simple. Entity A creates corporation B and multihomes > corporation B. Entity A moves half of their need into corporation B > to qualify for an ARIN /24, then moves corporation B back inside > Entity A through section 8.2. > More gong banging. Do you know how much it costs today in the US to setup a corporation? If it's worth it that much to the small org to keep it's /24 and not renumber, then go for it! They will make some lawyer happy and pay for the down payment on his yacht. Then a year later when they want to use a /23 mask internally they will have screwed themselves. Meanwhile their competitors will spend the money on a better network infrastructure and be done with their renumbering. I seem to remember you always advising this approach when it came to shifting from IPv4 to IPv6, Owen. >> throwing the baby out with the bathwater and has no recognition >> for the benefit to the community of forcing orgs to use contiguous >> subnets. >> > > But there is no baby and the bathwater appears to smell pretty foul > at this point. > > Org's today aren't forced to use contiguous subnets. With 8.3, that's > only going to get a whole lot worse going forward. > Yeah well I get that your POed about 8.3 - write a policy proposal to fix it, please, and stop trying to make every other policy proposal discussion a referendum on 8.3 Ted > Owen > > From owen at delong.com Thu May 3 06:47:02 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 3 May 2012 03:47:02 -0700 Subject: [arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <4FA24ADB.2080209@ipinc.net> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F9EB67D.8080005@arin.net> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <4FA01422.6030402@chl.com> <4FA07531.4040906@chl.com> <4FA0E93E.6010507@ipinc.net> <5398F743-1274-4EB0-BBE6-283A356AFE23@delong.com> <4FA24ADB.2080209@ipinc.net> Message-ID: <2F05BC2B-8F60-4F6A-AC7A-3E6ECA2B6714@delong.com> On May 3, 2012, at 2:07 AM, Ted Mittelstaedt wrote: > On 5/2/2012 11:58 PM, Owen DeLong wrote: >>> Yes it's difficult to renumber. But, the org renumbering is >>> getting something for their trouble - that is, they are getting >>> more IP addresses. Many small end user orgs in the past have >>> renumbered-and-returned just fine under 4.3.6.2 I don't see that >>> suddenly in year 2012 that something new and special has come along >>> that now makes renumbering impossible for these orgs. >>> >> >> Uh, no, Ted, they haven't. Please refer back to Leslie's policy >> experience report. >> >>> But ARIN must put a barrier up to simply request-without-renumber >>> otherwise the end user orgs will simply not do it. The proposal >>> is >> >> Why is that so bad? Today, an organization that needs a /20 is free >> to go out and purchase 16 discreet /24s and advertise all of them. > > yeah, yeah please stop with the 8.3 gong banging. > Either disaggregation is a concern and we should, therefore focus on the largest sources of such disaggregation, or, it isn't. Pretending that this proposal is bad because of the potential for disaggregation which is rather mathematically limited while accepting the disaggregation consequences of 8.3 which are virtually unlimited seems disingenuous at best and an effort to lock out the little guy to subsidize larger players at worst. >> We're talking about an organization that started with a /24 or a /23 >> expanding to a maximum of 4 /24s before the policy becomes moot >> anyway. > > I would submit that most orgs that start with a /24 either are low-to-no > growth and will never really need anything beyond the /24, or they > have a good enough mousetrap that people are clawing for what they > have and they can easily justify jumping from a /24 to a /22 on the > first go around. > In which case, this proposal would have even less impact than what I suggested. I was trying to place bounds on the worst case. >> In fact, the current way for an organization that has a /24 >> and doesn't want to renumber to get to having 2 /24s worth of space >> is quite simple. Entity A creates corporation B and multihomes >> corporation B. Entity A moves half of their need into corporation B >> to qualify for an ARIN /24, then moves corporation B back inside >> Entity A through section 8.2. >> > > More gong banging. > I'm not sure why you call this gong banging. Bottom line, it's a very simple way to circumvent the policy we are seeking to repeal, so, the policy is merely an inconvenience, doesn't achieve the desired objective, and is far from being the worst offender among existing policies for the so-called problem at hand. > Do you know how much it costs today in the US to setup a corporation? > About $60 if you incorporate in Delaware, but, you don't have to incorporate to be an organization in the ARIN region. There are many other valid structures which are even cheaper. > If it's worth it that much to the small org to keep it's /24 and not > renumber, then go for it! They will make some lawyer happy and > pay for the down payment on his yacht. Then a year later when they > want to use a /23 mask internally they will have screwed themselves. $60 to avoid the pain of renumbering? Sign me up. Heck, I pay $100/year in ARIN fees to avoid the pain of renumbering and that's just for my house. > Meanwhile their competitors will spend the money on a better network infrastructure and be done with their renumbering. Really? How much network infrastructure can you buy for $60? > I seem to remember you always advising this approach when it came > to shifting from IPv4 to IPv6, Owen. Apples to oranges comparison. If you can call gong-banging (whatever that means), I think this qualifies as hand-waving. >>> throwing the baby out with the bathwater and has no recognition >>> for the benefit to the community of forcing orgs to use contiguous >>> subnets. >>> >> >> But there is no baby and the bathwater appears to smell pretty foul >> at this point. >> >> Org's today aren't forced to use contiguous subnets. With 8.3, that's >> only going to get a whole lot worse going forward. >> > > Yeah well I get that your POed about 8.3 - write a policy proposal to > fix it, please, and stop trying to make every other policy proposal > discussion a referendum on 8.3 I'm actually not POed about 8.3. I do think it's bad policy and I had my say about that. The community spoke and if you review the record, you'll find that the arbitrary deletion of the sunset clause was my only reason for voting against the policy. You'll also find that I voted in favor of 2011-1 and 2012-1 updates to 8.3. While I am not a fan of 8.3, I accepted that the majority of the community supported it and certain aspects of it were unfortunately vital for the time being. My subsequent comments about 8.3 have, I believe, been limited to: 1. Discussions of proposals to modify 8.2/8.3 2. This proposal Basic arithmetic says that 8.3 has much larger routing table implications than this proposal. My 8.3 comments aren't about trying to make this a referendum on 8.3. They're an effort to get the community to recognize the hypocrisy inherent in accepting 8.3 as currently written while objecting to this proposal. Owen (Speaking solely for myself and not in my capacity as an AC member) From izaac at setec.org Thu May 3 07:12:24 2012 From: izaac at setec.org (Izaac) Date: Thu, 3 May 2012 07:12:24 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <4FA1DA78.4090401@redbarn.org> 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> Message-ID: <20120503T105531Z@localhost> On Thu, May 03, 2012 at 01:08:08AM +0000, paul vixie wrote: > On 5/2/2012 11:44 PM, Dmitry Burkov wrote: > > ... It is not about it - the issue for me - should be RIR responsible for end user assignments data? > > someone has to be. we're not going to grow the internet economy another > order of magnitude if we continue to reduce the accountability of the > people and companies who can reserve unique resources. 'whois' or You're not going to grow the internet economy another order of magnitude under IPv4. It is exhausted. This fine-grained identification requirement is entirely the result of attempts to economize the use of the precious remainder. If the bureaucratic energy were redirected into IPv6 transition, we'd could begin to explore the kind of growth of which you speak. (Incidentally, do contact your local Austrian economist for a discussion about whether central planning or a free market are more efficient at allocating scarce resources.) -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From hannigan at gmail.com Thu May 3 08:14:06 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 3 May 2012 08:14:06 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> Message-ID: Hi Dan, The current PDP that we are operating under with respect to this proposal says that: "The Advisory Council evaluates policy proposals and develops them into technically sound and useful draft policies that, if adopted, will make a positive contribution to the Number Resource Policy Manual. " This proposal is technically sound; I believe that you would agree that we did address the technical concerns which were what the majority of what the opposition was on mailing list. The proposal is useful to the Internet technical community; it allows network operators to choose and was additionally noted to be useful by ARIN's outside legal counsel further benefiting the ARIN community. 2 in favor vs. every one opposed) is a much wider margin of consensus than many other proposals that we've passed of late (See 2011-1 for example). Consensus is not a good challenge for this proposal. With Section 8.3 and 2011-1 opening the door for transfer at-large, it would make sense for ASN's to be included in this as well and as such, the AC overwhelmingly adopted this proposal 10 in favor, 4 opposed, an even wider margin than the public support. In favor.. Best, Martin Hannigan Elected Advisory Council Member On Wed, May 2, 2012 at 3:32 PM, Alexander, Daniel < Daniel_Alexander at cable.comcast.com> wrote: > > I will probably get flamed for this one, but I wanted to try and explain > why I voted against this proposal during the AC meeting. > > If I borrow some wording from the proposed PDP, when the AC has to > determine consensus we have to determine whether the proposed change has > substantially more support than opposition in the community active in the > discussion. (56 PPML posts: 6 for, 3 against)(106 people in the room of > the Public Policy Meeting: 27 for, 11 against) We also have to consider > that the specific concerns expressed have been considered. This last part > is one of the reasons I voted against this proposal. > > I think that 2012-3 breaks new ground in that it has no technical need as > a foundation. This proposal allows a part of the community to do something > they want to do, rather than technically need to do. Bear with me here > before this splinters into days of argument. To be clear, I am not > suggesting this should not be allowed, rather question what is the > appropriate level of dissent or support for such a change. > > Some policy debates have to move past the dissenting opinions because the > implications may outweigh the result of not making a change. If, however > there are no technical downside, then similar consideration has to be > given to both opinions of the community. One cannot dismiss the personal > opinions of those who object to the change when those in dissent are > supposed to accept the opinions of those who want it for no other reason. > We need a serious debate over what is the appropriate level of support for > a non-technical proposal. > > Because of this, I do not feel that appropriate consensus has been reached > and this proposal warrants further discussion. Not only for the merits of > the proposal itself but for the implications that this change has on how > we are referred to as the "Internet Technical Community". > > Dan Alexander > AC Member > > > On 4/30/12 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. > > _______________________________________________ > 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 Thu May 3 09:09:56 2012 From: bill at herrin.us (William Herrin) Date: Thu, 3 May 2012 09:09:56 -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> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <8EB5E74F-9E9C-45BB-8608-8052E45610A4@netconsonance.com> Message-ID: On 5/3/12, Jimmy Hess wrote: > DNS pinning beyond a normal DNS TTL period would be an anomaly, and > is likely a unique issue to be addressed by the end user (by > rebooting their equipment). Due respect Jimmy, read up on DNS pinning. The whole point is to hold the first IP address beyond the the TTL. It's the solution to a particularly nasty javascript vulnerability. Roughly speaking, Javascript limits outbound connections to the server from which the javascript came from. If they didn't, going to a web page with javascript could result in an address scan of the interior of the firewall where the web browser sits. It didn't take too long for someone to figure out that by altering the IP address associated with a DNS name back and forth between the external (real) server address and various addresses suspected to be inside the target's firewall, an attacker could sidestep Javascript's security. So along comes DNS pinning. Once javascript is running on a page, that IP address is locked in. Some browsers are smart enough to allow a new lookup once the user takes an action which would cause the javascript program to terminate. Others lock it in as long as anything from that server is up in any window. Still others made the simplest choice: the address is locked in so long as the browser is running. There's still an open hole when the target is behind a configured web proxy but that's a low enough probability event to discourage the general attack vector. Also it only really applies to configured proxies, not the more common transparent proxies. > Browser windows don't get left open for 3 months. Even if the DNS > pinning _DID_ happen to be broken in some version of a major browser > in use by users; that can be addressed by the amount of time that > the renumbering is performed over. Depends on the user. I have plenty of browser windows on my desktop that have been open for more than a month. They generally stay open until either the browser becomes choppy enough that I decide to restart it or until the OS becomes unstable enough that I give up on suspend/restore. 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 Thu May 3 11:12:54 2012 From: bill at herrin.us (William Herrin) Date: Thu, 3 May 2012 11:12:54 -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 5/2/12, Owen DeLong wrote: > OTOH, anyone can now buy as many /24s on the transfer market as they can > justify, even one /24 at a time (we got rid of the single aggregate > provision in the transfer policy), so, if you want to worry about nibbling > away at the routing table, let's focus on the potential for problems there, > rather than in this piddling little policy. Hi Owen, 8.3 today says "can demonstrate the need for such resources in the amount which they can justify under current ARIN policies." There are changes to that already in the pipeline, yes? Yet the policy -today- (if the implementation matches the words) would seem to be that section 4 requirements apply to 8.3 transfers as well. On Thu, May 3, 2012 at 2:58 AM, Owen DeLong wrote: > In fact, the current way for an organization that has a /24 and >doesn't want to renumber to get to having 2 /24s worth of space >is quite simple. Entity A creates corporation B and multihomes >corporation B. This sort of process is my standing recommendation to my large end user customers. At the /22 level even before the current /24 policy. With large end users, one often finds that the central IT organization is completely hopeless. It's routinely picked clean of anyone talented enough to support a paying product, leaving it a bastion of mediocrity. Even where not hopeless, central IT is rarely structured in a way capable of facilitating a particular product group's need for ARIN resources. When a particular product team needs to stand up a multihomed network for a new product, creating a distinct company to hold the network resources allows them to approach ARIN with a clean slate. They're judged only on their direct needs rather than be faced with the impossible situation of addressing the larger company's activity, activity over which they have no influence. Policy-wise this works out more or less OK. Standing up the distinct company is not an action taken lightly or cheaply. While oddly constructed, it provides the same back pressure against careless consumption that the policy's strictures are aimed at. This probably isn't a "wonderful" result of current policies but I haven't heard a credible alternative. ARIN and the RIRs are the major gatekeepers to the BGP table and nobody has identified a practical way to move money from the people who introduce routes to the people who provide slots in the deployed routers. You've heard the quote that "Democracy is the worst form of government except for all the others." Well, same principle at work here. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lee at dilkie.com Thu May 3 11:43:30 2012 From: lee at dilkie.com (Lee Dilkie) Date: Thu, 03 May 2012 11:43:30 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <20120503T105531Z@localhost> 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> Message-ID: <4FA2A7A2.4060302@dilkie.com> On 5/3/2012 7:12 AM, Izaac wrote: > > and companies who can reserve unique resources. 'whois' or > You're not going to grow the internet economy another order of magnitude > under IPv4. It is exhausted. This fine-grained identification > requirement is entirely the result of attempts to economize the use of > the precious remainder. If the bureaucratic energy were redirected into > IPv6 transition, we'd could begin to explore the kind of growth of which > you speak. > > (Incidentally, do contact your local Austrian economist for a discussion > about whether central planning or a free market are more efficient at > allocating scarce resources.) > Here here... a lot of fretting and wasted energy over an ever shrinking pool... I'm not opposed to simply giving out all the rest of the ipv4 addresses, first come, first served, and washing our hands of this mess. The market will end up re-distributing them anyway. Concentrate on IPv6. That's where the growth and, IMHO, ARIN needs to be. -lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From JOHN at egh.com Thu May 3 12:27:55 2012 From: JOHN at egh.com (John Santos) Date: Thu, 3 May 2012 12:27:55 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: Message-ID: <1120503122722.977P-100000@Ives.egh.com> No one has presented *any* technical justification for this proposal. Opposed. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From owen at delong.com Thu May 3 15:09:44 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 3 May 2012 12:09:44 -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 May 3, 2012, at 8:12 AM, William Herrin wrote: > On 5/2/12, Owen DeLong wrote: >> OTOH, anyone can now buy as many /24s on the transfer market as they can >> justify, even one /24 at a time (we got rid of the single aggregate >> provision in the transfer policy), so, if you want to worry about nibbling >> away at the routing table, let's focus on the potential for problems there, >> rather than in this piddling little policy. > > Hi Owen, > > 8.3 today says "can demonstrate the need for such resources in the > amount which they can justify under current ARIN policies." There are > changes to that already in the pipeline, yes? Yet the policy -today- > (if the implementation matches the words) would seem to be that > section 4 requirements apply to 8.3 transfers as well. > Only with respect to amount. That's a key difference. If I can justify a /16 under section 4, ARIN will issue a /16, or, if they cannot, offer me the choice between the largest block they can issue or a slot in the waiting list (see waiting list policy adopted about a year ago). Under 8.3, if I can justify a /16, since we removed the "as a single aggregate" clause from 8.3 (and unfortunately due to an error in positioning, even before), ARIN will approve an 8.3 transfer whether that /16 worth of space comes from a single /16, 16 /20s, or 256 /24s or any other combination of /24s and larger that make up that amount of space. This is current operational practice as implemented by ARIN. One need look no further than the Nortel->Micr0$0ft transaction to see clear evidence of this. > On Thu, May 3, 2012 at 2:58 AM, Owen DeLong wrote: >> In fact, the current way for an organization that has a /24 and >> doesn't want to renumber to get to having 2 /24s worth of space >> is quite simple. Entity A creates corporation B and multihomes >> corporation B. > > This sort of process is my standing recommendation to my large end > user customers. At the /22 level even before the current /24 policy. > Meh. > With large end users, one often finds that the central IT organization > is completely hopeless. It's routinely picked clean of anyone talented > enough to support a paying product, leaving it a bastion of > mediocrity. Even where not hopeless, central IT is rarely structured > in a way capable of facilitating a particular product group's need for > ARIN resources. > Sounds like a radically different form of internal problem. It has not been my experience in dealing with several large end user organizations that this always holds true, but, I would agree it is not uncommon. However, I'm not sure it's relevant to the debate on this proposal. Owen From owen at delong.com Thu May 3 15:16:15 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 3 May 2012 12:16:15 -0700 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> Message-ID: <957F052C-3C9D-428E-B06C-CC1CF35111FB@delong.com> On May 3, 2012, at 5:14 AM, Martin Hannigan wrote: > > > Hi Dan, > > The current PDP that we are operating under with respect to this proposal says that: > > "The Advisory Council evaluates policy proposals and develops them into technically sound and useful draft policies that, if adopted, will make a positive contribution to the Number Resource Policy Manual. " > > This proposal is technically sound; I believe that you would agree that we did address the technical concerns which were what the majority of what the opposition was on mailing list. The proposal is useful to the Internet technical community; it allows network operators to choose and was additionally noted to be useful by ARIN's outside legal counsel further benefiting the ARIN community. > I am not convinced that the proposal is technically sound and I think there are damaging aspects to it. > 2 in favor vs. every one opposed) is a much wider margin of consensus than many other proposals that we've passed of late (See 2011-1 for example). Consensus is not a good challenge for this proposal. It's also within the range of consensus by which we have abandoned proposals in the past. > With Section 8.3 and 2011-1 opening the door for transfer at-large, it would make sense for ASN's to be included in this as well and as such, the AC overwhelmingly adopted this proposal 10 in favor, 4 opposed, an even wider margin than the public support. > Which is one of the many reasons that a lot of us were wary about 8.3 to begin with and tried to include such protections as a sunset clause. 8.3 opened that door due to exigent circumstances for IPv4 runout. No such exigent circumstances exist with respect to ASNs. Further, the AC did not adopt this proposal, the AC sent this proposal to last call. Owen From paul at redbarn.org Thu May 3 15:30:04 2012 From: paul at redbarn.org (paul vixie) Date: Thu, 03 May 2012 19:30:04 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <50075C07-6D84-4753-83E3-DFDE52A229E6@burkov.aha.ru> <4FA1DF23.1000807@redbarn.org> Message-ID: <4FA2DCBC.6020303@redbarn.org> On 5/3/2012 2:38 AM, Dmitry Burkov wrote: > Even today we have all necessary info to identify anyone on the net no. perhaps in russia this is true, but in the countries of the arin region this is not true. > = the isuue is only should be concentarated or not? that issue does not arise, because the information is not available in any form. then, speaking hypothetically: >> as a child of the cold war, i know well the dangers of superconcentrated >> power. however, i am not willing to trade away accountability to get >> avoidance of concentration of power. instead i propose that the >> community formulate reasonable rules that balance the rights of >> registrants with the rights of the rest of the community, and that the >> community maintain vigilant control of the instruments they create >> (whether RIR's or governments or armies or police forces) to prevent >> abuses of any necessarily concentrated power. > it is now more the issue of cost of operations and legal risks... sorry - but I think that it should not be rirs responsibility as we have no direct en user contracts the lack of end user contracts does not come into it. as a policy matter, arin's contracted parties can be required by community-driven policy to keep accurate records as to their suballocations, to make those records openly available for noncommercial purposes, and to pass that restriction onward to any sub-suballocations and so forth. i don't see how that creates the danger you're describing or any subset thereof. and i don't see anyone other than the RIRs who could do it. and i don't see any way to continue the internet's prior growth curve without this. your move. paul From christoph.blecker at ubc.ca Thu May 3 15:45:19 2012 From: christoph.blecker at ubc.ca (Blecker, Christoph) Date: Thu, 3 May 2012 19:45:19 +0000 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <4F9EC985.1030503@arin.net> References: <4F9EC985.1030503@arin.net> Message-ID: <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> Simple version: I do not support this policy as written. Longer version: I have yet to see or fully understand a situation where a specified ASN transfer is either technically required or even preferable, outside of a network engineer just wanting a particular number. The way I currently understand it, the "vanity licence plate" metaphor that some have been using seems pretty accurate. This opens the door for assigning artificial value to a number that not many people outside network engineers know or should know about. I would support this change if there was a reasonable technical need behind it (and perhaps somebody can enlighten me). At ARIN XXIX, there was also been some talk around bankruptcy courts and not having a transfer policy around ASNs for that. Perhaps a more elegant solution would be to create a new 8.x policy to specifically address transferring resources from entities in bankruptcy, similar to the way 8.2 addresses M&As. That way, ARIN has more guidance to what the community thinks, and judges involved have specific recommendations from us in how the community views these resources. Overall, I think more discussion is needed. Cheers, Christoph -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: April-30-12 10:19 AM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN-2012-3: ASN 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-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. From jeffrey.lyon at blacklotus.net Thu May 3 16:08:19 2012 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 3 May 2012 16:08:19 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> Message-ID: On Thu, May 3, 2012 at 3:45 PM, Blecker, Christoph wrote: > Simple version: I do not support this policy as written. > > Longer version: > I have yet to see or fully understand a situation where a specified ASN transfer is either technically required or even preferable, outside of a network engineer just wanting a particular number. The way I currently understand it, the "vanity licence plate" metaphor that some have been using seems pretty accurate. This opens the door for assigning artificial value to a number that not many people outside network engineers know or should know about. I would support this change if there was a reasonable technical need behind it (and perhaps somebody can enlighten me). > > At ARIN XXIX, there was also been some talk around bankruptcy courts and not having a transfer policy around ASNs for that. Perhaps a more elegant solution would be to create a new 8.x policy to specifically address transferring resources from entities in bankruptcy, similar to the way 8.2 addresses M&As. That way, ARIN has more guidance to what the community thinks, and judges involved have specific recommendations from us in how the community views these resources. > > Overall, I think more discussion is needed. > > Cheers, > Christoph > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN > Sent: April-30-12 10:19 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] ARIN-2012-3: ASN 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-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. > _______________________________________________ > 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. The problem with many proposals, this one especially, is that every situation is always looked at from the perspective of "is this technically required." I would argue that many look at every situation from the perspective of "would I benefit from this?" To be fair, most here do align "I benefit" with stewardship, but herein lies the problem. PPML, policy meetings, etc. are highly dominated by "old school" engineers. I vote at ARIN elections, and consistently see speeches that detail how long each candidate has been supporting stewardship, how they helped pioneer the internet, and so forth. That's great, we love you for it and you command much respect from your peers. The problem that we now face in 2012 is that the community is substantially larger and more diverse than the representation within the ARIN policy community. Some quick observations: - PPML is predominately engineers, most of whom are not involved in financial decision making for their organizations (or are from non-profits) - Attendees at ARIN meetings are predominately the same folks. - Given these observations, i'm willing to assume that those who actually vote at ARIN elections are mostly the same crew of old school policy makers. What i'm attempting to argue is that this does not have to be a zero sum game. Just because this policy could benefit the management, bean counters, and marketing gurus of any given commercial enterprise does not mean that stewardship has been abandoned, that ARIN is becoming commercialized, or that we're somehow setting a bad precedent. Many could benefit substantially from the transferability of ASN's, its just unfortunately that the ultimate decision to strike down this proposal are not the same group of folks. Reiterating my position of "Strongly Support," -- Jeffrey A. Lyon, CISSP President | (757) 304-0668 http://www.blacklotus.net Black Lotus Communications From bill at herrin.us Thu May 3 16:21:40 2012 From: bill at herrin.us (William Herrin) Date: Thu, 3 May 2012 16:21:40 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <4FA2DCBC.6020303@redbarn.org> 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <50075C07-6D84-4753-83E3-DFDE52A229E6@burkov.aha.ru> <4FA1DF23.1000807@redbarn.org> <4FA2DCBC.6020303@redbarn.org> Message-ID: On Thu, May 3, 2012 at 3:30 PM, paul vixie wrote: > and i don't see anyone other than the RIRs who could do it. > > and i don't see any way to continue the internet's prior growth curve > without this. Hi Paul, As ISPs begin to make use of the carrier NAT space where a single global IP serves hundreds of customers, is it really necessary for ARIN to spot-check the identities of the customers sitting behind a particular address in order to verify that the use is legitimate? It would seem to me to be a failure of imagination if we can't find some less intrusive way to decide if the use has been faked. Besides, as someone else pointed out, customer lists don't prove anything unless ARIN staff pick up the phone and start calling. Should we expect ARIN to start randomly polling our customers to keep us honest? Isn't this all a little much? We made a policy decision to cut off public reporting at /29 for a reason. And we DO expect folks to pick up the phone and call the folks listed for /29's over network abuse or whatever. And report it to ARIN if it turns out to be fake. But if ARIN can't find a way to treat private sub-/29 reporting as a request of last resort, maybe it just shouldn't be available at all. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmaimon at chl.com Thu May 3 16:28:44 2012 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 03 May 2012 16:28:44 -0400 Subject: [arin-ppml] ARIN-prop-168 Promote 4byte ASN Usage In-Reply-To: References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FA02C10.7060408@arin.net> <513304D5-E827-4F53-AD4A-2D0EB9E9777F@delong.com> <4FA188EC.6030406@chl.com> Message-ID: <4FA2EA7C.5000709@chl.com> Owen, Thanks for the excellent feedback. I suppose at this time I can wait and see if the AC wants to adopt the proposal and to work on it or if a rewrite is in order. I'll give it some thought. Joe Owen DeLong wrote: > On May 2, 2012, at 12:20 PM, Joe Maimon wrote: > >> Hey Owen, >> >> Owen DeLong wrote: >>> I could support this policy with the following changes: >>> >>> 5.2.2 Remove "AS Number or" from the first sentence. >> >> To clarify, you are objecting to language that would allow an org to request a specific AS from ARIN, assuming it knows it is available. >> >> Yes, this allows an org the chance to try and get an aesthetically or otherwise pleasing ASN they may not have otherwise. >> >> Whats the harm in that? >> > I'm generally opposed to putting ARIN in the "custom license plate" business because I think there are other better higher priorities for number resource management. > >> But if dropping it is all it would take to win public support, its an easy loss. >> > Don't know about that. Certainly dropping it is a requirement to garner my support. > >>> 5.2.3 I don't understand what causes are being rectified, so, this entire >>> paragraph does not yet make sense to me. I would appreciate clarification >>> from the author. >> >> In the simplest case, it would allow ARIN to explain to the room at some future ppm why 4byte ASN utilization is so low, put the pages in the wiki, document and present to the community other potentially valid concerns, produce material that can be useful to parties involved in similar situations, etc... >> >> Yes, this may allow ARIN to operate a 4byte wall of shame. >> > I have no problem with policy enabling ARIN to operate a 4-octet wall of shame. However, if that is the intent, let's have the paragraph say that. I can't even parse what it says currently. > > I don't think ARIN knows why 4-octet ASN utilization is so low (in the ARIN region and uniquely in the ARIN region, btw). > >>> 5.2.4 I would prefer to see a longer period. >> Anything from 12-48 months is fine with me, personally. >> >> However, consider that this restriction as written applies to both 8.2 and 8.3 transfers. >> > I would modify to remove the restriction from 8.2 transfers and set the limit at 48 months (if we're going to allow 8.3 transfers of ASNs at all which I still feel is a bad idea). > >>> 5.2.5 I don't really see a purpose to this clause. I would delete it. >> >> An organization that wants to transfer an ASN, but cannot because 5.2.4 applies to it, has the option to exchange the ASN for a 5.2.1 which has no such restriction, should they wish to avail themselves of it. >> >> I suppose some grace time for renumbering may not be a bad idea. >> > Ah, but if we eliminate 5.2.3 as I suggested, that becomes inoperative. > >>> 5.2.6 is a no-op. It should be removed. >> >> Its there to prevent ARIN staff from concluding that in order to implement 5.2.2 they need to publish an entire list of available ASNs, which they may reasonably do so without making it explicitly non-dependent. >> > Move that statement to the rational. It's an operational concern, not a policy issue. > >>> 5.2.7 should also be removed. The policy can be retired by a proposal that >>> achieves community consensus. There is no need for an auto- >>> expiry process that is optional at the discretion of staff. >> >> How much effort is expended on policy cleanup for unused sections? >> > A fair amount, actually. I don't think that there are many, if any unused or obsolete sections currently in the NRPM and there have been several proposals which have removed them just in my tenure so far on the AC (a little more than 4 years) and many more in the decade+ that I have been active in the policy process. > >> Without active interest, I dont expect such a proposal to ever show up, unless the ARIN staff solicits one for disuse. So in that case, let them just remove it at that point. >> > In the past, we have generally eschewed sunset clauses. As such, I don't think having one in this policy is particularly more desirable than any of the past cases where the community has opted not to put one in. > >> Also not a pivotal aspect of the proposal. >> >> >>> I don't believe this policy will do anything to achieve the objective stated >>> in the title, however, perhaps that is because I cannot decipher 5.2.3. >>> If the author manages to sufficiently clarify 5.2.3 and/or modify the policy >>> such that it would demonstrably achieve the titled objective, I would >>> support that objective. >>> >>> Otherwise, it just looks like an attempt to back-door ASN transfers which >>> I oppose. >>> >>> >>> Owen >> >> The proposal was written with the expectation that directed ASN transfers are likely to be allowed via policy sometime soon, it is not intended to allow or disallow them on its own, except to add this additional restriction, applicable ONLY inasmuch as an ASN transfer is allowed, either via 8.2 currently or as 8.3 might be amended. >> > Then it should say that. The proposal for ASN transfers is (unfortunately) in last call, but, it has not been recommended to the board for adoption, let alone been adopted. > > Owen > > > From cgrundemann at gmail.com Thu May 3 16:31:11 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 3 May 2012 14:31:11 -0600 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> Message-ID: On Thu, May 3, 2012 at 2:08 PM, Jeffrey Lyon wrote: > Many > could benefit substantially from the transferability of ASN's, "Who?" & "How?" appear to be the relevant bits here. -- @ChrisGrundemann http://chrisgrundemann.com From michael+ppml at burnttofu.net Thu May 3 17:10:30 2012 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Thu, 03 May 2012 14:10:30 -0700 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> Message-ID: <4FA2F446.6090605@burnttofu.net> On 5/3/12 1:08 PM, Jeffrey Lyon wrote: > What i'm attempting to argue is that this does not have to be a zero > sum game. Just because this policy could benefit the management, bean > counters, and marketing gurus of any given commercial enterprise does > not mean that stewardship has been abandoned, that ARIN is becoming > commercialized, or that we're somehow setting a bad precedent. Many > could benefit substantially from the transferability of ASN's, its > just unfortunately that the ultimate decision to strike down this > proposal are not the same group of folks. > > Reiterating my position of "Strongly Support," When I vote in ARIN elections, I vote for people who understand and can represent viewpoints other than their own. They can go beyond their experiences and self-interest and understand the larger needs of the community. It's the different between leadership and simple representation. I'll note that many AC members that I have spoken to support this policy despite the fact that it is not in their narrow interest to do so. Regarding the statement about PPML being predominantly engineers, I take issue with the idea that engineers can't understand business or marketing concepts. Not only do engineers need to worry about destabilizing this important thing we are responsible for (i.e. the Internet), we have to understand the business, economic, and political aspects of everything we do. We need to understand the nexus of technology and policy. That's why we follow PPML. (Moreover, PPML is not only engineers--there are business people here, LE, etc.) Although the larger community has asked many times for use cases for this policy, the very best we have come up with is to have numbers we can remember. That and the bankruptcy issue (which I agree is compelling). The truth is, we really don't know what kind of negative effects we are creating when we allow for this monetization of a number that has never been of value in the past. No other RIR is currently entertaining such a transfer policy, so we have no experience to go on. This is similar to the excellent points that Heather Schiller made at ARIN 29. Given that we don't know the effects of a wide-open ASN transfer policy, I agree with Christoph that we should define the scope of the policy narrowly, to encompass the one use case we can find. I am opposed to the policy as written, re-iterating my already-counted vote at ARIN 29. michael From joelja at bogus.com Thu May 3 16:55:56 2012 From: joelja at bogus.com (Joel jaeggli) Date: Thu, 03 May 2012 13:55:56 -0700 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <50075C07-6D84-4753-83E3-DFDE52A229E6@burkov.aha.ru> <4FA1DF23.1000807@redbarn.org> <4FA2DCBC.6020303@redbarn.org> Message-ID: <4FA2F0DC.80505@bogus.com> On 5/3/12 13:21 , William Herrin wrote: > On Thu, May 3, 2012 at 3:30 PM, paul vixie wrote: >> and i don't see anyone other than the RIRs who could do it. >> >> and i don't see any way to continue the internet's prior growth curve >> without this. > > Hi Paul, > > As ISPs begin to make use of the carrier NAT space where a single > global IP serves hundreds of customers, is it really necessary for > ARIN to spot-check the identities of the customers sitting behind a > particular address in order to verify that the use is legitimate? ranges used by nat translators should be documented as such. they are not customer assignments. I've done this in the course of direct assignment requests. I have not yet been asked to demonstrate outgoing port utlization efficiency whatever that my imply at some future date. > It would seem to me to be a failure of imagination if we can't find > some less intrusive way to decide if the use has been faked. > > Besides, as someone else pointed out, customer lists don't prove > anything unless ARIN staff pick up the phone and start calling. Should > we expect ARIN to start randomly polling our customers to keep us > honest? > > Isn't this all a little much? > > We made a policy decision to cut off public reporting at /29 for a > reason. And we DO expect folks to pick up the phone and call the folks > listed for /29's over network abuse or whatever. And report it to ARIN > if it turns out to be fake. But if ARIN can't find a way to treat > private sub-/29 reporting as a request of last resort, maybe it just > shouldn't be available at all. > > Regards, > Bill Herrin > > > From bill at herrin.us Thu May 3 17:19:50 2012 From: bill at herrin.us (William Herrin) Date: Thu, 3 May 2012 17:19:50 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <4FA2F0DC.80505@bogus.com> 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <50075C07-6D84-4753-83E3-DFDE52A229E6@burkov.aha.ru> <4FA1DF23.1000807@redbarn.org> <4FA2DCBC.6020303@redbarn.org> <4FA2F0DC.80505@bogus.com> Message-ID: On 5/3/12, Joel jaeggli wrote: > On 5/3/12 13:21 , William Herrin wrote: >> On Thu, May 3, 2012 at 3:30 PM, paul vixie wrote: >>> and i don't see anyone other than the RIRs who could do it. >>> >>> and i don't see any way to continue the internet's prior growth curve >>> without this. >> >> As ISPs begin to make use of the carrier NAT space where a single >> global IP serves hundreds of customers, is it really necessary for >> ARIN to spot-check the identities of the customers sitting behind a >> particular address in order to verify that the use is legitimate? > > ranges used by nat translators should be documented as such. they are > not customer assignments. I've done this in the course of direct > assignment requests. I have not yet been asked to demonstrate outgoing > port utlization efficiency whatever that my imply at some future date. Hi Joel, Has anyone at ARIN promised you it won't do so in your next round? Unless I misunderstood John Curran, he said that and anything else which consumes IP addresses is fair game. He said they don't ask egregiously. But they also won't go out of their way to avoid asking. 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 May 3 18:04:29 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Thu, 3 May 2012 18:04:29 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> Message-ID: <94E6B1D4-78C2-4895-90B3-34D326D40617@eyeconomics.com> On May 3, 2012, at 4:08 PM, Jeffrey Lyon wrote: > On Thu, May 3, 2012 at 3:45 PM, Blecker, Christoph > wrote: >> Simple version: I do not support this policy as written. >> >> Longer version: >> I have yet to see or fully understand a situation where a specified ASN transfer is either technically required or even preferable, outside of a network engineer just wanting a particular number. The way I currently understand it, the "vanity licence plate" metaphor that some have been using seems pretty accurate. This opens the door for assigning artificial value to a number that not many people outside network engineers know or should know about. I would support this change if there was a reasonable technical need behind it (and perhaps somebody can enlighten me). >> >> At ARIN XXIX, there was also been some talk around bankruptcy courts and not having a transfer policy around ASNs for that. Perhaps a more elegant solution would be to create a new 8.x policy to specifically address transferring resources from entities in bankruptcy, similar to the way 8.2 addresses M&As. That way, ARIN has more guidance to what the community thinks, and judges involved have specific recommendations from us in how the community views these resources. >> >> Overall, I think more discussion is needed. >> >> Cheers, >> Christoph >> >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >> Sent: April-30-12 10:19 AM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] ARIN-2012-3: ASN 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-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. >> _______________________________________________ >> 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. > > The problem with many proposals, this one especially, is that every > situation is always looked at from the perspective of "is this > technically required." I would argue that many look at every situation > from the perspective of "would I benefit from this?" To be fair, most > here do align "I benefit" with stewardship, but herein lies the > problem. > > PPML, policy meetings, etc. are highly dominated by "old school" > engineers. I vote at ARIN elections, and consistently see speeches > that detail how long each candidate has been supporting stewardship, > how they helped pioneer the internet, and so forth. That's great, we > love you for it and you command much respect from your peers. The > problem that we now face in 2012 is that the community is > substantially larger and more diverse than the representation within > the ARIN policy community. Some quick observations: > > - PPML is predominately engineers, most of whom are not involved in > financial decision making for their organizations (or are from > non-profits) > - Attendees at ARIN meetings are predominately the same folks. > - Given these observations, i'm willing to assume that those who > actually vote at ARIN elections are mostly the same crew of old school > policy makers. > > What i'm attempting to argue is that this does not have to be a zero > sum game. Just because this policy could benefit the management, bean > counters, and marketing gurus of any given commercial enterprise does > not mean that stewardship has been abandoned, that ARIN is becoming > commercialized, or that we're somehow setting a bad precedent. In theory, stewardship interests and "bean counting" interests might indeed be the same; in practice, they rarely are. While I don't place much stock in the distinctions that you make here, they do help to illuminate the hole in this argument. Stewardship requires a balancing of interests not only along the continuum of old-school engineers, new-age bean counters, and other diverse (but seemingly silent/invisible) stakeholder groups in the present-day ARIN policy community. It also entails balancing interests along a complete different dimension -- i.e., the one that separates *current* stewardship policy stakeholders (a.k.a. "incumbents") and *future* community members (a.k.a. prospective "new entrants"). On a good day it's just possible, with significant time and attention, to come up with stewardship policy solutions that satisfy that balancing requirement in both dimensions... or at least it is when the stakeholder community(s) are defined in explicitly technical terms. Throw "bean counter" interests into that mix, however, and that balancing exercise becomes impossible. If you have any doubts about this, I suggest that you try to imagine how you might feel if ASN privatization had taken place back in 1993-1994, before your network existed (or transitioned to BGP4/IDR). Now imagine that your best option for obtaining an ASN was your least favorite upstream provider. For extra points, you could also try imagining that you live somewhere where the total number of reachable upstream providers is between 0-2. If you can imagine yourself and/or your own "bean counters" being indifferent between that scenario -- or any other other that you can come up with -- and the current scenario in which you are able to obtain an ASN on neutral, technically defined, non-adversarial terms, then I encourage you to share it with the list; I will maintain an open mind. Thanks, TV P.S. IMO, that overlooked, forward-looking aspect of the stakeholder mandate is also one of the most important distinguishing features that separates what routing and addressing industry members do in this domain, individually and collectively, from the sort of activities that tend to attract very unfriendly (read: "unprofitable") attention from DOJ and other competition authorities. It's also the one thing that distinguishes what policy community members have chosen to do with respect to the disposition of IPv4 from what former Soviet politburo members chose to do with respect to the disposition of Russia's "public" assets back in 1991-1992. Please think *very* carefully abandoning that part of our mandate. From celestea at usc.edu Thu May 3 18:46:32 2012 From: celestea at usc.edu (Celeste Anderson) Date: Thu, 3 May 2012 15:46:32 -0700 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <4FA2F446.6090605@burnttofu.net> References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> <4FA2F446.6090605@burnttofu.net> Message-ID: <01fa01cd297e$96685350$c338f9f0$@usc.edu> +1 -- I am opposed to the policy as written for much the same reasons stated by Michael. --celeste. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Sinatra Sent: Thursday, May 03, 2012 2:11 PM To: Jeffrey Lyon Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call On 5/3/12 1:08 PM, Jeffrey Lyon wrote: > What i'm attempting to argue is that this does not have to be a zero > sum game. Just because this policy could benefit the management, bean > counters, and marketing gurus of any given commercial enterprise does > not mean that stewardship has been abandoned, that ARIN is becoming > commercialized, or that we're somehow setting a bad precedent. Many > could benefit substantially from the transferability of ASN's, its > just unfortunately that the ultimate decision to strike down this > proposal are not the same group of folks. > > Reiterating my position of "Strongly Support," When I vote in ARIN elections, I vote for people who understand and can represent viewpoints other than their own. They can go beyond their experiences and self-interest and understand the larger needs of the community. It's the different between leadership and simple representation. I'll note that many AC members that I have spoken to support this policy despite the fact that it is not in their narrow interest to do so. Regarding the statement about PPML being predominantly engineers, I take issue with the idea that engineers can't understand business or marketing concepts. Not only do engineers need to worry about destabilizing this important thing we are responsible for (i.e. the Internet), we have to understand the business, economic, and political aspects of everything we do. We need to understand the nexus of technology and policy. That's why we follow PPML. (Moreover, PPML is not only engineers--there are business people here, LE, etc.) Although the larger community has asked many times for use cases for this policy, the very best we have come up with is to have numbers we can remember. That and the bankruptcy issue (which I agree is compelling). The truth is, we really don't know what kind of negative effects we are creating when we allow for this monetization of a number that has never been of value in the past. No other RIR is currently entertaining such a transfer policy, so we have no experience to go on. This is similar to the excellent points that Heather Schiller made at ARIN 29. Given that we don't know the effects of a wide-open ASN transfer policy, I agree with Christoph that we should define the scope of the policy narrowly, to encompass the one use case we can find. I am opposed to the policy as written, re-iterating my already-counted vote at ARIN 29. michael _______________________________________________ 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 tvest at eyeconomics.com Thu May 3 20:13:06 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Thu, 3 May 2012 20:13:06 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> <94E6B1D4-78C2-4895-90B3-34D326D40617@eyeconomics.com> Message-ID: <6A446997-8F76-4637-A60E-6A4449F6DD6E@eyeconomics.com> On May 3, 2012, at 6:46 PM, Bill Darte wrote: > Tom is that a voice in support or opposition to this proposal?\ > Thanks, > bd Hi Bill, The latter. Regards, TV > On Thu, May 3, 2012 at 3:04 PM, Tom Vest wrote: > > On May 3, 2012, at 4:08 PM, Jeffrey Lyon wrote: > > > On Thu, May 3, 2012 at 3:45 PM, Blecker, Christoph > > wrote: > >> Simple version: I do not support this policy as written. > >> > >> Longer version: > >> I have yet to see or fully understand a situation where a specified ASN transfer is either technically required or even preferable, outside of a network engineer just wanting a particular number. The way I currently understand it, the "vanity licence plate" metaphor that some have been using seems pretty accurate. This opens the door for assigning artificial value to a number that not many people outside network engineers know or should know about. I would support this change if there was a reasonable technical need behind it (and perhaps somebody can enlighten me). > >> > >> At ARIN XXIX, there was also been some talk around bankruptcy courts and not having a transfer policy around ASNs for that. Perhaps a more elegant solution would be to create a new 8.x policy to specifically address transferring resources from entities in bankruptcy, similar to the way 8.2 addresses M&As. That way, ARIN has more guidance to what the community thinks, and judges involved have specific recommendations from us in how the community views these resources. > >> > >> Overall, I think more discussion is needed. > >> > >> Cheers, > >> Christoph > >> > >> > >> -----Original Message----- > >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN > >> Sent: April-30-12 10:19 AM > >> To: arin-ppml at arin.net > >> Subject: [arin-ppml] ARIN-2012-3: ASN 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-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. > >> _______________________________________________ > >> 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. > > > > The problem with many proposals, this one especially, is that every > > situation is always looked at from the perspective of "is this > > technically required." I would argue that many look at every situation > > from the perspective of "would I benefit from this?" To be fair, most > > here do align "I benefit" with stewardship, but herein lies the > > problem. > > > > PPML, policy meetings, etc. are highly dominated by "old school" > > engineers. I vote at ARIN elections, and consistently see speeches > > that detail how long each candidate has been supporting stewardship, > > how they helped pioneer the internet, and so forth. That's great, we > > love you for it and you command much respect from your peers. The > > problem that we now face in 2012 is that the community is > > substantially larger and more diverse than the representation within > > the ARIN policy community. Some quick observations: > > > > - PPML is predominately engineers, most of whom are not involved in > > financial decision making for their organizations (or are from > > non-profits) > > - Attendees at ARIN meetings are predominately the same folks. > > - Given these observations, i'm willing to assume that those who > > actually vote at ARIN elections are mostly the same crew of old school > > policy makers. > > > > What i'm attempting to argue is that this does not have to be a zero > > sum game. Just because this policy could benefit the management, bean > > counters, and marketing gurus of any given commercial enterprise does > > not mean that stewardship has been abandoned, that ARIN is becoming > > commercialized, or that we're somehow setting a bad precedent. > > In theory, stewardship interests and "bean counting" interests might indeed be the same; in practice, they rarely are. > While I don't place much stock in the distinctions that you make here, they do help to illuminate the hole in this argument. > Stewardship requires a balancing of interests not only along the continuum of old-school engineers, new-age bean counters, and other diverse (but seemingly silent/invisible) stakeholder groups in the present-day ARIN policy community. It also entails balancing interests along a complete different dimension -- i.e., the one that separates *current* stewardship policy stakeholders (a.k.a. "incumbents") and *future* community members (a.k.a. prospective "new entrants"). On a good day it's just possible, with significant time and attention, to come up with stewardship policy solutions that satisfy that balancing requirement in both dimensions... or at least it is when the stakeholder community(s) are defined in explicitly technical terms. Throw "bean counter" interests into that mix, however, and that balancing exercise becomes impossible. > > If you have any doubts about this, I suggest that you try to imagine how you might feel if ASN privatization had taken place back in 1993-1994, before your network existed (or transitioned to BGP4/IDR). Now imagine that your best option for obtaining an ASN was your least favorite upstream provider. For extra points, you could also try imagining that you live somewhere where the total number of reachable upstream providers is between 0-2. > > If you can imagine yourself and/or your own "bean counters" being indifferent between that scenario -- or any other other that you can come up with -- and the current scenario in which you are able to obtain an ASN on neutral, technically defined, non-adversarial terms, then I encourage you to share it with the list; I will maintain an open mind. > > Thanks, > > TV > > P.S. IMO, that overlooked, forward-looking aspect of the stakeholder mandate is also one of the most important distinguishing features that separates what routing and addressing industry members do in this domain, individually and collectively, from the sort of activities that tend to attract very unfriendly (read: "unprofitable") attention from DOJ and other competition authorities. It's also the one thing that distinguishes what policy community members have chosen to do with respect to the disposition of IPv4 from what former Soviet politburo members chose to do with respect to the disposition of Russia's "public" assets back in 1991-1992. Please think *very* carefully abandoning that part of our mandate. > > > _______________________________________________ > 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 christoph.blecker at ubc.ca Thu May 3 21:56:00 2012 From: christoph.blecker at ubc.ca (Blecker, Christoph) Date: Fri, 4 May 2012 01:56:00 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> My interpretation of this proposal is not removing the ability of ARIN to require details on customers with less than 8 addresses, but more moving it to a last resort. A couple questions: - Is this how ARIN staff would interpret this proposal? - How does this differ from right now? I would suspect that digging into this detail level would be only happen today, if other reasonable methods of verification were exhausted. - Is this what the author intended, or was it meant to stop this practice all together? Much of the discussion seems to be around completely removing the ability of ARIN to ask into this level of detail, however that's not how I interpret what was written. Cheers, Christoph > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of William Herrin > Sent: April-26-12 3:39 PM > To: policy at arin.net > Cc: ARIN PPML > Subject: [arin-ppml] 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: > > 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. From jcurran at arin.net Thu May 3 22:36:07 2012 From: jcurran at arin.net (John Curran) Date: Fri, 4 May 2012 02:36:07 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> Message-ID: <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> On May 3, 2012, at 9:56 PM, Blecker, Christoph wrote: > My interpretation of this proposal is not removing the ability of ARIN to require details on customers with less than 8 addresses, but more moving it to a last resort. > > A couple questions: > - Is this how ARIN staff would interpret this proposal? Staff review is underway now. At first glance, it appears that the proposal is not a policy change for management of number resources but a suggestion for a specific portion of the request verification process. > - How does this differ from right now? I would suspect that digging into this detail level would be only happen today, if other reasonable methods of verification were exhausted. If the utilization of an address block is predicated upon these customer assignments, then we are likely to ask for this information in the end. > - Is this what the author intended, or was it meant to stop this practice > all together? Much of the discussion seems to be around completely removing > the ability of ARIN to ask into this level of detail, however that's not how > I interpret what was written. I believe the author intended to discourage ARIN from requesting such information except as the last resort, but unless ARIN can accept counts of customer assignments as valid without further verification, it may not result in any meaningful change for many requests (those where the utilization is based on customer assignments) I hope this helps, and thanks for your message! /John John Curran President and CEO ARIN From jeffrey.lyon at blacklotus.net Thu May 3 23:23:51 2012 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 3 May 2012 23:23:51 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <94E6B1D4-78C2-4895-90B3-34D326D40617@eyeconomics.com> References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> <94E6B1D4-78C2-4895-90B3-34D326D40617@eyeconomics.com> Message-ID: On Thu, May 3, 2012 at 6:04 PM, Tom Vest wrote: > > On May 3, 2012, at 4:08 PM, Jeffrey Lyon wrote: > >> On Thu, May 3, 2012 at 3:45 PM, Blecker, Christoph >> wrote: >>> Simple version: I do not support this policy as written. >>> >>> Longer version: >>> I have yet to see or fully understand a situation where a specified ASN transfer is either technically required or even preferable, outside of a network engineer just wanting a particular number. The way I currently understand it, the "vanity licence plate" metaphor that some have been using seems pretty accurate. This opens the door for assigning artificial value to a number that not many people outside network engineers know or should know about. I would support this change if there was a reasonable technical need behind it (and perhaps somebody can enlighten me). >>> >>> At ARIN XXIX, there was also been some talk around bankruptcy courts and not having a transfer policy around ASNs for that. Perhaps a more elegant solution would be to create a new 8.x policy to specifically address transferring resources from entities in bankruptcy, similar to the way 8.2 addresses M&As. That way, ARIN has more guidance to what the community thinks, and judges involved have specific recommendations from us in how the community views these resources. >>> >>> Overall, I think more discussion is needed. >>> >>> Cheers, >>> Christoph >>> >>> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >>> Sent: April-30-12 10:19 AM >>> To: arin-ppml at arin.net >>> Subject: [arin-ppml] ARIN-2012-3: ASN 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-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. >>> _______________________________________________ >>> 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. >> >> The problem with many proposals, this one especially, is that every >> situation is always looked at from the perspective of "is this >> technically required." I would argue that many look at every situation >> from the perspective of "would I benefit from this?" To be fair, most >> here do align "I benefit" with stewardship, but herein lies the >> problem. >> >> PPML, policy meetings, etc. are highly dominated by "old school" >> engineers. I vote at ARIN elections, and consistently see speeches >> that detail how long each candidate has been supporting stewardship, >> how they helped pioneer the internet, and so forth. That's great, we >> love you for it and you command much respect from your peers. The >> problem that we now face in 2012 is that the community is >> substantially larger and more diverse than the representation within >> the ARIN policy community. Some quick observations: >> >> - PPML is predominately engineers, most of whom are not involved in >> financial decision making for their organizations (or are from >> non-profits) >> - Attendees at ARIN meetings are predominately the same folks. >> - Given these observations, i'm willing to assume that those who >> actually vote at ARIN elections are mostly the same crew of old school >> policy makers. >> >> What i'm attempting to argue is that this does not have to be a zero >> sum game. Just because this policy could benefit the management, bean >> counters, and marketing gurus of any given commercial enterprise does >> not mean that stewardship has been abandoned, that ARIN is becoming >> commercialized, or that we're somehow setting a bad precedent. > > In theory, stewardship interests and "bean counting" interests might indeed be the same; in practice, they rarely are. > While I don't place much stock in the distinctions that you make here, they do help to illuminate the hole in this argument. > Stewardship requires a balancing of interests not only along the continuum of old-school engineers, new-age bean counters, and other diverse (but seemingly silent/invisible) stakeholder groups in the present-day ARIN policy community. It also entails balancing interests along a complete different dimension -- i.e., the one that separates *current* stewardship policy stakeholders (a.k.a. "incumbents") and *future* community members (a.k.a. prospective "new entrants"). On a good day it's just possible, with significant time and attention, to come up with stewardship policy solutions that satisfy that balancing requirement in both dimensions... or at least it is when the stakeholder community(s) are defined in explicitly technical terms. Throw "bean counter" interests into that mix, however, and that balancing exercise becomes impossible. > > If you have any doubts about this, I suggest that you try to imagine how you might feel if ASN privatization had taken place back in 1993-1994, before your network existed (or transitioned to BGP4/IDR). Now imagine that your best option for obtaining an ASN was your least favorite upstream provider. For extra points, you could also try imagining that you live somewhere where the total number of reachable upstream providers is between 0-2. > > If you can imagine yourself and/or your own "bean counters" being indifferent between that scenario -- or any other other that you can come up with -- and the current scenario in which you are able to obtain an ASN on neutral, technically defined, non-adversarial terms, then I encourage you to share it with the list; I will maintain an open mind. > > Thanks, > > TV > > P.S. IMO, that overlooked, forward-looking aspect of the stakeholder mandate is also one of the most important distinguishing features that separates what routing and addressing industry members do in this domain, individually and collectively, from the sort of activities that tend to attract very unfriendly (read: "unprofitable") attention from DOJ and other competition authorities. It's also the one thing that distinguishes what policy community members have chosen to do with respect to the disposition of IPv4 from what former Soviet politburo members chose to do with respect to the disposition of Russia's "public" assets back in 1991-1992. Please think *very* carefully abandoning that part of our mandate. > > > _______________________________________________ > 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. Tom, I am not tracking on your example pertaining to ASN privatization. I'm in support of organizations being able to transfer their ASN resources, not in support of entities being required to petition telecom oligopolies to obtain resources. I am strictly in support of proposals that give our constituents more freedoms, not less. IT/IS, management, and accounting are closely related, often intersecting disciplines. I strongly believe that the opinions stated by those opposed in this discussion thread are those of the former, not of the latter. All 3 (and probably some others) are ARIN stakeholders that must be represented. This is not to say that the needs of management and accountants must completely supersede those of IT/IS, but rather that those needs can be addressed in a manner that does not unduly burden others. -- Jeffrey A. Lyon, CISSP President | (757) 304-0668 http://www.blacklotus.net Black Lotus Communications From narten at us.ibm.com Fri May 4 00:53:02 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 04 May 2012 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201205040453.q444r2EV018843@rotala.raleigh.ibm.com> Total of 135 messages in the last 7 days. script run at: Fri May 4 00:53:02 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 12.59% | 17 | 11.30% | 121002 | bill at herrin.us 9.63% | 13 | 10.71% | 114714 | owen at delong.com 6.67% | 9 | 7.84% | 83931 | jrhett at netconsonance.com 5.93% | 8 | 5.05% | 54039 | jcurran at arin.net 5.19% | 7 | 5.21% | 55791 | info at arin.net 5.19% | 7 | 4.71% | 50464 | mysidia at gmail.com 4.44% | 6 | 5.02% | 53720 | tedm at ipinc.net 3.70% | 5 | 4.31% | 46106 | jeffrey.lyon at blacklotus.net 2.96% | 4 | 4.88% | 52256 | hannigan at gmail.com 3.70% | 5 | 3.49% | 37412 | dburk at burkov.aha.ru 3.70% | 5 | 2.83% | 30337 | jbates at brightok.net 2.96% | 4 | 3.15% | 33687 | lee at dilkie.com 2.96% | 4 | 2.97% | 31780 | jmaimon at chl.com 2.96% | 4 | 2.36% | 25303 | cgrundemann at gmail.com 2.96% | 4 | 2.34% | 25057 | jlewis at lewis.org 2.96% | 4 | 2.10% | 22473 | david at airbits.com 2.22% | 3 | 2.11% | 22566 | daniel_alexander at cable.comcast.com 2.22% | 3 | 1.86% | 19951 | paul at redbarn.org 1.48% | 2 | 2.46% | 26352 | tvest at eyeconomics.com 1.48% | 2 | 1.90% | 20378 | scottleibrand at gmail.com 1.48% | 2 | 1.54% | 16496 | kevinb at thewire.ca 1.48% | 2 | 1.51% | 16206 | christoph.blecker at ubc.ca 1.48% | 2 | 1.49% | 15905 | lar at mwtcorp.net 1.48% | 2 | 1.22% | 13024 | narten at us.ibm.com 0.74% | 1 | 0.99% | 10648 | mike at nationwideinc.com 0.74% | 1 | 0.77% | 8272 | cb.list6 at gmail.com 0.74% | 1 | 0.76% | 8091 | farmer at umn.edu 0.74% | 1 | 0.74% | 7946 | celestea at usc.edu 0.74% | 1 | 0.73% | 7868 | marla.azinger at ftr.com 0.74% | 1 | 0.69% | 7398 | joelja at bogus.com 0.74% | 1 | 0.69% | 7346 | michael+ppml at burnttofu.net 0.74% | 1 | 0.64% | 6852 | frnkblk at iname.com 0.74% | 1 | 0.62% | 6599 | rbf+arin-ppml at panix.com 0.74% | 1 | 0.56% | 5954 | izaac at setec.org 0.74% | 1 | 0.45% | 4848 | john at egh.com --------+------+--------+----------+------------------------ 100.00% | 135 |100.00% | 1070772 | Total From tvest at eyeconomics.com Fri May 4 01:32:22 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 4 May 2012 01:32:22 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> <94E6B1D4-78C2-4895-90B3-34D326D40617@eyeconomics.com> Message-ID: <3513D82F-63DD-4EE6-AB81-285572F8A99C@eyeconomics.com> On May 3, 2012, at 11:23 PM, Jeffrey Lyon wrote: > On Thu, May 3, 2012 at 6:04 PM, Tom Vest wrote: >> >> On May 3, 2012, at 4:08 PM, Jeffrey Lyon wrote: >> >>> On Thu, May 3, 2012 at 3:45 PM, Blecker, Christoph >>> wrote: >>>> Simple version: I do not support this policy as written. >>>> >>>> Longer version: >>>> I have yet to see or fully understand a situation where a specified ASN transfer is either technically required or even preferable, outside of a network engineer just wanting a particular number. The way I currently understand it, the "vanity licence plate" metaphor that some have been using seems pretty accurate. This opens the door for assigning artificial value to a number that not many people outside network engineers know or should know about. I would support this change if there was a reasonable technical need behind it (and perhaps somebody can enlighten me). >>>> >>>> At ARIN XXIX, there was also been some talk around bankruptcy courts and not having a transfer policy around ASNs for that. Perhaps a more elegant solution would be to create a new 8.x policy to specifically address transferring resources from entities in bankruptcy, similar to the way 8.2 addresses M&As. That way, ARIN has more guidance to what the community thinks, and judges involved have specific recommendations from us in how the community views these resources. >>>> >>>> Overall, I think more discussion is needed. >>>> >>>> Cheers, >>>> Christoph >>>> >>>> >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >>>> Sent: April-30-12 10:19 AM >>>> To: arin-ppml at arin.net >>>> Subject: [arin-ppml] ARIN-2012-3: ASN 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-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. >>>> _______________________________________________ >>>> 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. >>> >>> The problem with many proposals, this one especially, is that every >>> situation is always looked at from the perspective of "is this >>> technically required." I would argue that many look at every situation >>> from the perspective of "would I benefit from this?" To be fair, most >>> here do align "I benefit" with stewardship, but herein lies the >>> problem. >>> >>> PPML, policy meetings, etc. are highly dominated by "old school" >>> engineers. I vote at ARIN elections, and consistently see speeches >>> that detail how long each candidate has been supporting stewardship, >>> how they helped pioneer the internet, and so forth. That's great, we >>> love you for it and you command much respect from your peers. The >>> problem that we now face in 2012 is that the community is >>> substantially larger and more diverse than the representation within >>> the ARIN policy community. Some quick observations: >>> >>> - PPML is predominately engineers, most of whom are not involved in >>> financial decision making for their organizations (or are from >>> non-profits) >>> - Attendees at ARIN meetings are predominately the same folks. >>> - Given these observations, i'm willing to assume that those who >>> actually vote at ARIN elections are mostly the same crew of old school >>> policy makers. >>> >>> What i'm attempting to argue is that this does not have to be a zero >>> sum game. Just because this policy could benefit the management, bean >>> counters, and marketing gurus of any given commercial enterprise does >>> not mean that stewardship has been abandoned, that ARIN is becoming >>> commercialized, or that we're somehow setting a bad precedent. >> >> In theory, stewardship interests and "bean counting" interests might indeed be the same; in practice, they rarely are. >> While I don't place much stock in the distinctions that you make here, they do help to illuminate the hole in this argument. >> Stewardship requires a balancing of interests not only along the continuum of old-school engineers, new-age bean counters, and other diverse (but seemingly silent/invisible) stakeholder groups in the present-day ARIN policy community. It also entails balancing interests along a complete different dimension -- i.e., the one that separates *current* stewardship policy stakeholders (a.k.a. "incumbents") and *future* community members (a.k.a. prospective "new entrants"). On a good day it's just possible, with significant time and attention, to come up with stewardship policy solutions that satisfy that balancing requirement in both dimensions... or at least it is when the stakeholder community(s) are defined in explicitly technical terms. Throw "bean counter" interests into that mix, however, and that balancing exercise becomes impossible. >> >> If you have any doubts about this, I suggest that you try to imagine how you might feel if ASN privatization had taken place back in 1993-1994, before your network existed (or transitioned to BGP4/IDR). Now imagine that your best option for obtaining an ASN was your least favorite upstream provider. For extra points, you could also try imagining that you live somewhere where the total number of reachable upstream providers is between 0-2. >> >> If you can imagine yourself and/or your own "bean counters" being indifferent between that scenario -- or any other other that you can come up with -- and the current scenario in which you are able to obtain an ASN on neutral, technically defined, non-adversarial terms, then I encourage you to share it with the list; I will maintain an open mind. >> >> Thanks, >> >> TV >> >> P.S. IMO, that overlooked, forward-looking aspect of the stakeholder mandate is also one of the most important distinguishing features that separates what routing and addressing industry members do in this domain, individually and collectively, from the sort of activities that tend to attract very unfriendly (read: "unprofitable") attention from DOJ and other competition authorities. It's also the one thing that distinguishes what policy community members have chosen to do with respect to the disposition of IPv4 from what former Soviet politburo members chose to do with respect to the disposition of Russia's "public" assets back in 1991-1992. Please think *very* carefully abandoning that part of our mandate. >> >> >> _______________________________________________ >> 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. > > Tom, > > I am not tracking on your example pertaining to ASN privatization. I'm > in support of organizations being able to transfer their ASN > resources, not in support of entities being required to petition > telecom oligopolies to obtain resources. I am strictly in support of > proposals that give our constituents more freedoms, not less. > > IT/IS, management, and accounting are closely related, often > intersecting disciplines. I strongly believe that the opinions stated > by those opposed in this discussion thread are those of the former, > not of the latter. All 3 (and probably some others) are ARIN > stakeholders that must be represented. This is not to say that the > needs of management and accountants must completely supersede those of > IT/IS, but rather that those needs can be addressed in a manner that > does not unduly burden others. Hi Jeffrey, For the record, my own policy views are based on personal experience that straddles all three of the disciplines you cite, and is probably influenced more by my past "bean counting" work than anything else -- so you can nix that theory. I'm not worried about things that might happen, but rather about things that *will* happen, because they always happen when very clever people with specialized expertise encounter obscure but potentially lucrative strategic (technical/regulatory) arbitrage opportunities. What invariably happens is they "go for it" -- always -- even in cases where the loophole exploiters themselves are fully aware that what they're trying to do could (and likely will) have very far-reaching adverse consequences. They ignore such risks because doing so will pay off for their employers, at least in the short-term; because it'll be good for their own careers, reputations, and personal fortunes; because the competitive marketplace assures that if they don't go for it first, someone else will, eventually; and ultimately because it's great fun to be (or at least play at) master of the universe. Call that the "anti-stewardship" orientation. For better or worse, that's the role that many of us play (or have played at some point) in our professional lives, outside of this forum. And that's precisely why, IMO, we would all do well to be a little less coy about the realities of the marketplace in this forum. Because in the end, the best way to minimize any future temptation that you or I might face to go "rogue trader," and also to minimize the risk/harm that we and everyone else *will* face if enough of y/our competitors should succumb to such temptations, is to make sure that the exploitable loopholes that give rise to such temptations are closed, or at least made less attractive and kept under constant, close scrutiny. As for the claim that an ASN transfer policy would provide more freedom for stakeholders, that again completely ignores the temporal dimension that distinguishes "stewardship" from blind faith in markets. Your liberty to become a commercial ASN broker today would be purchased at the expense of future ASN seekers, who will be deprived of the opportunity that you and every other "incumbent" number resource stakeholder has enjoyed to date -- namely, the opportunity to obtain number resources on non-adversarial, technical needs-based terms from a non-competitor. I apologize if my previous examples were unclear, but let me try one more time, using the above argument. Say you currently work in the kind of environment where "good ideas" for cutting costs and/or increasing revenues are recognized and rewarded -- and where the most highly prized ideas of all are those that can be expected to pay off for a long long time, e.g., because they are opaque to competitors and third parties in general. The actual job you do might be in an IT/IS/engineering department, or in "business development," or in executive management. It really doesn't matter which: you're a "bean counter" of some kind, regardless of your actual title. From that perspective, please choose which of the three business conditions you would prefer: 1. I possess surplus reserves of a critical resource that my current competitors must obtain in order to grow, and without which prospective future competitors cannot even enter my market. They don't necessarily have to get the critical resource from me, but if they don't their only alternative is to get it from another market actor that has appx. the same strategic/competitive interests that I have with respect to this particular market. 2. I do not have enough of the critical resource to realize my Internet operations-business potential, and my only options are to try to obtain the resource from a current competitor, or from some other entity that knows that selling that resource to me will effectively make me a potential future competitor. Unless/until I obtain (more of) that critical resource, I cannot enter the Internet operations business/market and/or grow my business to its full potential. 3. I do not have enough of the critical resource, but if I can credibly demonstrate that my ability to enter the market and/or grow is contingent (only) on possession of that critical resource, then I can always obtain what I "need" on neutral, transparent, non-preferential terms from a non-competitor. You are free to choose (1), but only if you can find, say, 10 other current stakeholders that are willing to opt out of (2) in favor of (3). And even if you can manage that, you'll still need to come up with an argument that would persuasive enough to convince future stakeholders that their fortunes would be improved by being your (or someone else's) customer for ASNs, as opposed to being no ones customer for ASNs. I know it can be tempting to imagine that this would be a perfectly reasonable arrangement, which is why I encourage you to go through the whole hypothetical scenario once more, but this time imagining yourself in the same bean counter role, albeit a decade after all commercially viable ASNs have been privatized. This time you get no choice; you're stuck with (3). If you are truly indifferent between those two alternatives -- i.e., your bean counting aspirations would be equally fulfilled by status (1) or status (3), then you are to be commended for your genuine, consistent commitment to free market principles. I'm sure that ARIN will happily accept the return of your current ASNs, but no doubt the ASN transfer market will provide for whatever is needed thereafter. In fact, if everyone in favor of 2012-3 is willing to do the same, and abandon all claim to 100% of the ASNs currently in their possession, I just might be persuaded to support this policy. Any takers? TV From tvest at eyeconomics.com Fri May 4 01:44:39 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 4 May 2012 01:44:39 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call (typo correction) In-Reply-To: <3513D82F-63DD-4EE6-AB81-285572F8A99C@eyeconomics.com> References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> <94E6B1D4-78C2-4895-90B3-34D326D40617@eyeconomics.com> <3513D82F-63DD-4EE6-AB81-285572F8A99C@eyeconomics.com> Message-ID: On May 4, 2012, at 1:32 AM, Tom Vest wrote: > > On May 3, 2012, at 11:23 PM, Jeffrey Lyon wrote: > >> On Thu, May 3, 2012 at 6:04 PM, Tom Vest wrote: >>> >>> On May 3, 2012, at 4:08 PM, Jeffrey Lyon wrote: >>> >>>> On Thu, May 3, 2012 at 3:45 PM, Blecker, Christoph >>>> wrote: >>>>> Simple version: I do not support this policy as written. >>>>> >>>>> Longer version: >>>>> I have yet to see or fully understand a situation where a specified ASN transfer is either technically required or even preferable, outside of a network engineer just wanting a particular number. The way I currently understand it, the "vanity licence plate" metaphor that some have been using seems pretty accurate. This opens the door for assigning artificial value to a number that not many people outside network engineers know or should know about. I would support this change if there was a reasonable technical need behind it (and perhaps somebody can enlighten me). >>>>> >>>>> At ARIN XXIX, there was also been some talk around bankruptcy courts and not having a transfer policy around ASNs for that. Perhaps a more elegant solution would be to create a new 8.x policy to specifically address transferring resources from entities in bankruptcy, similar to the way 8.2 addresses M&As. That way, ARIN has more guidance to what the community thinks, and judges involved have specific recommendations from us in how the community views these resources. >>>>> >>>>> Overall, I think more discussion is needed. >>>>> >>>>> Cheers, >>>>> Christoph >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >>>>> Sent: April-30-12 10:19 AM >>>>> To: arin-ppml at arin.net >>>>> Subject: [arin-ppml] ARIN-2012-3: ASN 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-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. >>>>> _______________________________________________ >>>>> 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. >>>> >>>> The problem with many proposals, this one especially, is that every >>>> situation is always looked at from the perspective of "is this >>>> technically required." I would argue that many look at every situation >>>> from the perspective of "would I benefit from this?" To be fair, most >>>> here do align "I benefit" with stewardship, but herein lies the >>>> problem. >>>> >>>> PPML, policy meetings, etc. are highly dominated by "old school" >>>> engineers. I vote at ARIN elections, and consistently see speeches >>>> that detail how long each candidate has been supporting stewardship, >>>> how they helped pioneer the internet, and so forth. That's great, we >>>> love you for it and you command much respect from your peers. The >>>> problem that we now face in 2012 is that the community is >>>> substantially larger and more diverse than the representation within >>>> the ARIN policy community. Some quick observations: >>>> >>>> - PPML is predominately engineers, most of whom are not involved in >>>> financial decision making for their organizations (or are from >>>> non-profits) >>>> - Attendees at ARIN meetings are predominately the same folks. >>>> - Given these observations, i'm willing to assume that those who >>>> actually vote at ARIN elections are mostly the same crew of old school >>>> policy makers. >>>> >>>> What i'm attempting to argue is that this does not have to be a zero >>>> sum game. Just because this policy could benefit the management, bean >>>> counters, and marketing gurus of any given commercial enterprise does >>>> not mean that stewardship has been abandoned, that ARIN is becoming >>>> commercialized, or that we're somehow setting a bad precedent. >>> >>> In theory, stewardship interests and "bean counting" interests might indeed be the same; in practice, they rarely are. >>> While I don't place much stock in the distinctions that you make here, they do help to illuminate the hole in this argument. >>> Stewardship requires a balancing of interests not only along the continuum of old-school engineers, new-age bean counters, and other diverse (but seemingly silent/invisible) stakeholder groups in the present-day ARIN policy community. It also entails balancing interests along a complete different dimension -- i.e., the one that separates *current* stewardship policy stakeholders (a.k.a. "incumbents") and *future* community members (a.k.a. prospective "new entrants"). On a good day it's just possible, with significant time and attention, to come up with stewardship policy solutions that satisfy that balancing requirement in both dimensions... or at least it is when the stakeholder community(s) are defined in explicitly technical terms. Throw "bean counter" interests into that mix, however, and that balancing exercise becomes impossible. >>> >>> If you have any doubts about this, I suggest that you try to imagine how you might feel if ASN privatization had taken place back in 1993-1994, before your network existed (or transitioned to BGP4/IDR). Now imagine that your best option for obtaining an ASN was your least favorite upstream provider. For extra points, you could also try imagining that you live somewhere where the total number of reachable upstream providers is between 0-2. >>> >>> If you can imagine yourself and/or your own "bean counters" being indifferent between that scenario -- or any other other that you can come up with -- and the current scenario in which you are able to obtain an ASN on neutral, technically defined, non-adversarial terms, then I encourage you to share it with the list; I will maintain an open mind. >>> >>> Thanks, >>> >>> TV >>> >>> P.S. IMO, that overlooked, forward-looking aspect of the stakeholder mandate is also one of the most important distinguishing features that separates what routing and addressing industry members do in this domain, individually and collectively, from the sort of activities that tend to attract very unfriendly (read: "unprofitable") attention from DOJ and other competition authorities. It's also the one thing that distinguishes what policy community members have chosen to do with respect to the disposition of IPv4 from what former Soviet politburo members chose to do with respect to the disposition of Russia's "public" assets back in 1991-1992. Please think *very* carefully abandoning that part of our mandate. >>> >>> >>> _______________________________________________ >>> 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. >> >> Tom, >> >> I am not tracking on your example pertaining to ASN privatization. I'm >> in support of organizations being able to transfer their ASN >> resources, not in support of entities being required to petition >> telecom oligopolies to obtain resources. I am strictly in support of >> proposals that give our constituents more freedoms, not less. >> >> IT/IS, management, and accounting are closely related, often >> intersecting disciplines. I strongly believe that the opinions stated >> by those opposed in this discussion thread are those of the former, >> not of the latter. All 3 (and probably some others) are ARIN >> stakeholders that must be represented. This is not to say that the >> needs of management and accountants must completely supersede those of >> IT/IS, but rather that those needs can be addressed in a manner that >> does not unduly burden others. > > Hi Jeffrey, > > For the record, my own policy views are based on personal experience that straddles all three of the disciplines you cite, and is probably influenced more by my past "bean counting" work than anything else -- so you can nix that theory. I'm not worried about things that might happen, but rather about things that *will* happen, because they always happen when very clever people with specialized expertise encounter obscure but potentially lucrative strategic (technical/regulatory) arbitrage opportunities. What invariably happens is they "go for it" -- always -- even in cases where the loophole exploiters themselves are fully aware that what they're trying to do could (and likely will) have very far-reaching adverse consequences. They ignore such risks because doing so will pay off for their employers, at least in the short-term; because it'll be good for their own careers, reputations, and personal fortunes; because the competitive marketplace assures that if they don't go for it first, someone else will, eventually; and ultimately because it's great fun to be (or at least play at) master of the universe. Call that the "anti-stewardship" orientation. For better or worse, that's the role that many of us play (or have played at some point) in our professional lives, outside of this forum. And that's precisely why, IMO, we would all do well to be a little less coy about the realities of the marketplace in this forum. Because in the end, the best way to minimize any future temptation that you or I might face to go "rogue trader," and also to minimize the risk/harm that we and everyone else *will* face if enough of y/our competitors should succumb to such temptations, is to make sure that the exploitable loopholes that give rise to such temptations are closed, or at least made less attractive and kept under constant, close scrutiny. > > As for the claim that an ASN transfer policy would provide more freedom for stakeholders, that again completely ignores the temporal dimension that distinguishes "stewardship" from blind faith in markets. Your liberty to become a commercial ASN broker today would be purchased at the expense of future ASN seekers, who will be deprived of the opportunity that you and every other "incumbent" number resource stakeholder has enjoyed to date -- namely, the opportunity to obtain number resources on non-adversarial, technical needs-based terms from a non-competitor. > > I apologize if my previous examples were unclear, but let me try one more time, using the above argument. Say you currently work in the kind of environment where "good ideas" for cutting costs and/or increasing revenues are recognized and rewarded -- and where the most highly prized ideas of all are those that can be expected to pay off for a long long time, e.g., because they are opaque to competitors and third parties in general. The actual job you do might be in an IT/IS/engineering department, or in "business development," or in executive management. It really doesn't matter which: you're a "bean counter" of some kind, regardless of your actual title. From that perspective, please choose which of the three business conditions you would prefer: > > 1. I possess surplus reserves of a critical resource that my current competitors must obtain in order to grow, and without which prospective future competitors cannot even enter my market. They don't necessarily have to get the critical resource from me, but if they don't their only alternative is to get it from another market actor that has appx. the same strategic/competitive interests that I have with respect to this particular market. > > 2. I do not have enough of the critical resource to realize my Internet operations-business potential, and my only options are to try to obtain the resource from a current competitor, or from some other entity that knows that selling that resource to me will effectively make me a potential future competitor. Unless/until I obtain (more of) that critical resource, I cannot enter the Internet operations business/market and/or grow my business to its full potential. > > 3. I do not have enough of the critical resource, but if I can credibly demonstrate that my ability to enter the market and/or grow is contingent (only) on possession of that critical resource, then I can always obtain what I "need" on neutral, transparent, non-preferential terms from a non-competitor. Apologies for the confusion -- got the numbering a little mixed up below; now corrected... > You are free to choose (1), but only if you can find, say, 10 other current stakeholders that are willing to opt out of [[3]] in favor of [[2]]. And even if you can manage that, you'll still need to come up with an argument that would persuasive enough to convince future stakeholders that their fortunes would be improved by being your (or someone else's) customer for ASNs, as opposed to being no ones customer for ASNs. > > I know it can be tempting to imagine that this would be a perfectly reasonable arrangement, which is why I encourage you to go through the whole hypothetical scenario once more, but this time imagining yourself in the same bean counter role, albeit a decade after all commercially viable ASNs have been privatized. This time you get no choice; you're stuck with [[2]]. > > If you are truly indifferent between those two alternatives -- i.e., your bean counting aspirations would be equally fulfilled by status [[1]] or status [[2]], then you are to be commended for your genuine, consistent commitment to free market principles. I'm sure that ARIN will happily accept the return of your current ASNs, but no doubt the ASN transfer market will provide for whatever is needed thereafter. > > In fact, if everyone in favor of 2012-3 is willing to do the same, and abandon all claim to 100% of the ASNs currently in their possession, I just might be persuaded to support this policy. > > Any takers? > > TV > > From bill at herrin.us Fri May 4 07:45:46 2012 From: bill at herrin.us (William Herrin) Date: Fri, 4 May 2012 07:45:46 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <1120503122722.977P-100000@Ives.egh.com> References: <1120503122722.977P-100000@Ives.egh.com> Message-ID: On Thu, May 3, 2012 at 12:27 PM, John Santos wrote: > No one has presented *any* technical justification for this proposal. > > Opposed. On the one hand, I support the proposal. Whether or not there is a reason to allow something is not the appropriate standard here. If we can't show good cause why something should not be allowed then it should be. I mean seriously, God forbid someone blows their nose without first explaining to us why they want to. On Wed, May 2, 2012 at 3:32 PM, Alexander, Daniel wrote: > If I borrow some wording from the proposed PDP, when the AC has to > determine consensus we have to determine whether the proposed change has > substantially more support than opposition in the community active in the > discussion. (56 PPML posts: 6 for, 3 against)(106 people in the room of > the Public Policy Meeting: 27 for, 11 against) We also have to consider > that the specific concerns expressed have been considered. This last part > is one of the reasons I voted against this proposal. On the other hand, the AC paying attention to and _respecting_ minority dissent within the community is long overdue. I don't understand the dissent on this one. But since it exists, what's rush to get the policy on the books? Let's talk about it some more first. 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 Fri May 4 08:12:02 2012 From: bill at herrin.us (William Herrin) Date: Fri, 4 May 2012 08:12:02 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> Message-ID: On Thu, May 3, 2012 at 10:36 PM, John Curran wrote: > Staff review is underway now. ?At first glance, it appears that the proposal > is not a policy change for management of number resources but a suggestion > for a specific portion of the request verification process. Something's wrong here John. If we can't write a policy that says, "Err on the side of avoiding PII" and expect it to actually do something then the policy process is gravely broken. Seriously, if a hospital claims that 9/10ths of its use is DHCP pools for patient use is ARIN going to ask for a list of patients w/ addresses and phone numbers which used a particular pool? Of course not, in the U.S. that would be illegal. You'll find another way. So how do we write a policy which says, "Just use the other way all the time." 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 Fri May 4 08:19:13 2012 From: jcurran at arin.net (John Curran) Date: Fri, 4 May 2012 12:19:13 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> Message-ID: <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> On May 4, 2012, at 8:12 AM, William Herrin wrote: > On Thu, May 3, 2012 at 10:36 PM, John Curran wrote: >> Staff review is underway now. At first glance, it appears that the proposal >> is not a policy change for management of number resources but a suggestion >> for a specific portion of the request verification process. > > Something's wrong here John. If we can't write a policy that says, > "Err on the side of avoiding PII" and expect it to actually do > something then the policy process is gravely broken. Bill - In lieu of asking for customer reassignments data to support claimed utilization of an address block, what information do you propose that ARIN accept? Thanks, /John John Curran President and CEO ARIN From scottleibrand at gmail.com Fri May 4 08:42:55 2012 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 4 May 2012 05:42:55 -0700 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <3513D82F-63DD-4EE6-AB81-285572F8A99C@eyeconomics.com> References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> <94E6B1D4-78C2-4895-90B3-34D326D40617@eyeconomics.com> <3513D82F-63DD-4EE6-AB81-285572F8A99C@eyeconomics.com> Message-ID: Tom, Can you elaborate on whether you see ASNs as a scarce resource, or whether you see conditions under which they might become scarce? From my perspective, the fact that there are 4 billion 4-byte ASNs, which (unlike IPv4 and IPv6) interoperate quite well with 2-byte ASNs, means that I don't see how your argument about cornering a market for a critical resource would apply in this situation. Thanks, Scott On May 3, 2012, at 10:32 PM, Tom Vest wrote: > > On May 3, 2012, at 11:23 PM, Jeffrey Lyon wrote: > >> On Thu, May 3, 2012 at 6:04 PM, Tom Vest wrote: >>> >>> On May 3, 2012, at 4:08 PM, Jeffrey Lyon wrote: >>> >>>> On Thu, May 3, 2012 at 3:45 PM, Blecker, Christoph >>>> wrote: >>>>> Simple version: I do not support this policy as written. >>>>> >>>>> Longer version: >>>>> I have yet to see or fully understand a situation where a specified ASN transfer is either technically required or even preferable, outside of a network engineer just wanting a particular number. The way I currently understand it, the "vanity licence plate" metaphor that some have been using seems pretty accurate. This opens the door for assigning artificial value to a number that not many people outside network engineers know or should know about. I would support this change if there was a reasonable technical need behind it (and perhaps somebody can enlighten me). >>>>> >>>>> At ARIN XXIX, there was also been some talk around bankruptcy courts and not having a transfer policy around ASNs for that. Perhaps a more elegant solution would be to create a new 8.x policy to specifically address transferring resources from entities in bankruptcy, similar to the way 8.2 addresses M&As. That way, ARIN has more guidance to what the community thinks, and judges involved have specific recommendations from us in how the community views these resources. >>>>> >>>>> Overall, I think more discussion is needed. >>>>> >>>>> Cheers, >>>>> Christoph >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >>>>> Sent: April-30-12 10:19 AM >>>>> To: arin-ppml at arin.net >>>>> Subject: [arin-ppml] ARIN-2012-3: ASN 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-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. >>>>> _______________________________________________ >>>>> 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. >>>> >>>> The problem with many proposals, this one especially, is that every >>>> situation is always looked at from the perspective of "is this >>>> technically required." I would argue that many look at every situation >>>> from the perspective of "would I benefit from this?" To be fair, most >>>> here do align "I benefit" with stewardship, but herein lies the >>>> problem. >>>> >>>> PPML, policy meetings, etc. are highly dominated by "old school" >>>> engineers. I vote at ARIN elections, and consistently see speeches >>>> that detail how long each candidate has been supporting stewardship, >>>> how they helped pioneer the internet, and so forth. That's great, we >>>> love you for it and you command much respect from your peers. The >>>> problem that we now face in 2012 is that the community is >>>> substantially larger and more diverse than the representation within >>>> the ARIN policy community. Some quick observations: >>>> >>>> - PPML is predominately engineers, most of whom are not involved in >>>> financial decision making for their organizations (or are from >>>> non-profits) >>>> - Attendees at ARIN meetings are predominately the same folks. >>>> - Given these observations, i'm willing to assume that those who >>>> actually vote at ARIN elections are mostly the same crew of old school >>>> policy makers. >>>> >>>> What i'm attempting to argue is that this does not have to be a zero >>>> sum game. Just because this policy could benefit the management, bean >>>> counters, and marketing gurus of any given commercial enterprise does >>>> not mean that stewardship has been abandoned, that ARIN is becoming >>>> commercialized, or that we're somehow setting a bad precedent. >>> >>> In theory, stewardship interests and "bean counting" interests might indeed be the same; in practice, they rarely are. >>> While I don't place much stock in the distinctions that you make here, they do help to illuminate the hole in this argument. >>> Stewardship requires a balancing of interests not only along the continuum of old-school engineers, new-age bean counters, and other diverse (but seemingly silent/invisible) stakeholder groups in the present-day ARIN policy community. It also entails balancing interests along a complete different dimension -- i.e., the one that separates *current* stewardship policy stakeholders (a.k.a. "incumbents") and *future* community members (a.k.a. prospective "new entrants"). On a good day it's just possible, with significant time and attention, to come up with stewardship policy solutions that satisfy that balancing requirement in both dimensions... or at least it is when the stakeholder community(s) are defined in explicitly technical terms. Throw "bean counter" interests into that mix, however, and that balancing exercise becomes impossible. >>> >>> If you have any doubts about this, I suggest that you try to imagine how you might feel if ASN privatization had taken place back in 1993-1994, before your network existed (or transitioned to BGP4/IDR). Now imagine that your best option for obtaining an ASN was your least favorite upstream provider. For extra points, you could also try imagining that you live somewhere where the total number of reachable upstream providers is between 0-2. >>> >>> If you can imagine yourself and/or your own "bean counters" being indifferent between that scenario -- or any other other that you can come up with -- and the current scenario in which you are able to obtain an ASN on neutral, technically defined, non-adversarial terms, then I encourage you to share it with the list; I will maintain an open mind. >>> >>> Thanks, >>> >>> TV >>> >>> P.S. IMO, that overlooked, forward-looking aspect of the stakeholder mandate is also one of the most important distinguishing features that separates what routing and addressing industry members do in this domain, individually and collectively, from the sort of activities that tend to attract very unfriendly (read: "unprofitable") attention from DOJ and other competition authorities. It's also the one thing that distinguishes what policy community members have chosen to do with respect to the disposition of IPv4 from what former Soviet politburo members chose to do with respect to the disposition of Russia's "public" assets back in 1991-1992. Please think *very* carefully abandoning that part of our mandate. >>> >>> >>> _______________________________________________ >>> 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. >> >> Tom, >> >> I am not tracking on your example pertaining to ASN privatization. I'm >> in support of organizations being able to transfer their ASN >> resources, not in support of entities being required to petition >> telecom oligopolies to obtain resources. I am strictly in support of >> proposals that give our constituents more freedoms, not less. >> >> IT/IS, management, and accounting are closely related, often >> intersecting disciplines. I strongly believe that the opinions stated >> by those opposed in this discussion thread are those of the former, >> not of the latter. All 3 (and probably some others) are ARIN >> stakeholders that must be represented. This is not to say that the >> needs of management and accountants must completely supersede those of >> IT/IS, but rather that those needs can be addressed in a manner that >> does not unduly burden others. > > Hi Jeffrey, > > For the record, my own policy views are based on personal experience that straddles all three of the disciplines you cite, and is probably influenced more by my past "bean counting" work than anything else -- so you can nix that theory. I'm not worried about things that might happen, but rather about things that *will* happen, because they always happen when very clever people with specialized expertise encounter obscure but potentially lucrative strategic (technical/regulatory) arbitrage opportunities. What invariably happens is they "go for it" -- always -- even in cases where the loophole exploiters themselves are fully aware that what they're trying to do could (and likely will) have very far-reaching adverse consequences. They ignore such risks because doing so will pay off for their employers, at least in the short-term; because it'll be good for their own careers, reputations, and personal fortunes; because the competitive marketplace assures that if they don't go for > it first, someone else will, eventually; and ultimately because it's great fun to be (or at least play at) master of the universe. Call that the "anti-stewardship" orientation. For better or worse, that's the role that many of us play (or have played at some point) in our professional lives, outside of this forum. And that's precisely why, IMO, we would all do well to be a little less coy about the realities of the marketplace in this forum. Because in the end, the best way to minimize any future temptation that you or I might face to go "rogue trader," and also to minimize the risk/harm that we and everyone else *will* face if enough of y/our competitors should succumb to such temptations, is to make sure that the exploitable loopholes that give rise to such temptations are closed, or at least made less attractive and kept under constant, close scrutiny. > > As for the claim that an ASN transfer policy would provide more freedom for stakeholders, that again completely ignores the temporal dimension that distinguishes "stewardship" from blind faith in markets. Your liberty to become a commercial ASN broker today would be purchased at the expense of future ASN seekers, who will be deprived of the opportunity that you and every other "incumbent" number resource stakeholder has enjoyed to date -- namely, the opportunity to obtain number resources on non-adversarial, technical needs-based terms from a non-competitor. > > I apologize if my previous examples were unclear, but let me try one more time, using the above argument. Say you currently work in the kind of environment where "good ideas" for cutting costs and/or increasing revenues are recognized and rewarded -- and where the most highly prized ideas of all are those that can be expected to pay off for a long long time, e.g., because they are opaque to competitors and third parties in general. The actual job you do might be in an IT/IS/engineering department, or in "business development," or in executive management. It really doesn't matter which: you're a "bean counter" of some kind, regardless of your actual title. From that perspective, please choose which of the three business conditions you would prefer: > > 1. I possess surplus reserves of a critical resource that my current competitors must obtain in order to grow, and without which prospective future competitors cannot even enter my market. They don't necessarily have to get the critical resource from me, but if they don't their only alternative is to get it from another market actor that has appx. the same strategic/competitive interests that I have with respect to this particular market. > > 2. I do not have enough of the critical resource to realize my Internet operations-business potential, and my only options are to try to obtain the resource from a current competitor, or from some other entity that knows that selling that resource to me will effectively make me a potential future competitor. Unless/until I obtain (more of) that critical resource, I cannot enter the Internet operations business/market and/or grow my business to its full potential. > > 3. I do not have enough of the critical resource, but if I can credibly demonstrate that my ability to enter the market and/or grow is contingent (only) on possession of that critical resource, then I can always obtain what I "need" on neutral, transparent, non-preferential terms from a non-competitor. > > You are free to choose (1), but only if you can find, say, 10 other current stakeholders that are willing to opt out of (2) in favor of (3). And even if you can manage that, you'll still need to come up with an argument that would persuasive enough to convince future stakeholders that their fortunes would be improved by being your (or someone else's) customer for ASNs, as opposed to being no ones customer for ASNs. > > I know it can be tempting to imagine that this would be a perfectly reasonable arrangement, which is why I encourage you to go through the whole hypothetical scenario once more, but this time imagining yourself in the same bean counter role, albeit a decade after all commercially viable ASNs have been privatized. This time you get no choice; you're stuck with (3). > > If you are truly indifferent between those two alternatives -- i.e., your bean counting aspirations would be equally fulfilled by status (1) or status (3), then you are to be commended for your genuine, consistent commitment to free market principles. I'm sure that ARIN will happily accept the return of your current ASNs, but no doubt the ASN transfer market will provide for whatever is needed thereafter. > > In fact, if everyone in favor of 2012-3 is willing to do the same, and abandon all claim to 100% of the ASNs currently in their possession, I just might be persuaded to support this policy. > > Any takers? > > TV > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at herrin.us Fri May 4 10:24:20 2012 From: bill at herrin.us (William Herrin) Date: Fri, 4 May 2012 10:24:20 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> Message-ID: On 5/4/12, John Curran wrote: > In lieu of asking for customer reassignments data to support claimed > utilization of an address block, what information do you propose that > ARIN accept? Hi John, Proof of infrastructure? You can check whether or not equipment is in place with ordinary ratios for the claim. Proof of traffic? You can spot-check packet patterns to see if they're consistent with real users versus careless assignment. But let me turn the question around: ARIN staff have been doing this for quite a while. How would staff handle the hospital as ISP scenario I posited? HIIPA says you don't get to look at the user data. It's the law. So what would data would staff seek for their audit instead? 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 Fri May 4 11:02:50 2012 From: jcurran at arin.net (John Curran) Date: Fri, 4 May 2012 15:02:50 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> Message-ID: <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> On May 4, 2012, at 10:24 AM, William Herrin wrote: > On 5/4/12, John Curran wrote: >> In lieu of asking for customer reassignments data to support claimed >> utilization of an address block, what information do you propose that >> ARIN accept? > > Hi John, > > Proof of infrastructure? You can check whether or not equipment is in > place with ordinary ratios for the claim. I believe you are saying that ARIN should consider proof of infrastructure to be sufficient validation for an assertion of IP utilization typical for such equipment. We can do that rather than request customer reassignment information if the community so desires. I do not know whether it would encourage requests for additional resources from folks with otherwise lightly-utilized equipment, but the potential for completely fabricated requests would indeed be limited by the ability to prove actual infrastructure. > Proof of traffic? You can spot-check packet patterns to see if they're > consistent with real users versus careless assignment. We would need significantly more detail to understand exactly what traffic would constitute validation for an asserted IP address utilization. > But let me turn the question around: ARIN staff have been doing this > for quite a while. How would staff handle the hospital as ISP scenario > I posited? HIIPA says you don't get to look at the user data. It's the > law. So what would data would staff seek for their audit instead? Your hypothetical lacks sufficient detail to answer with certainty. It's likely we would request customer reassignment data to verify utilization. I am confident that sufficient information could be provided to ARIN under NDA as needed which would not violate HIPPA's "protected health information" requirements, just as we have been able to work with parties with PII, CPNI, and related issues. Thanks! /John John Curran President and CEO ARIN From bill at herrin.us Fri May 4 11:36:45 2012 From: bill at herrin.us (William Herrin) Date: Fri, 4 May 2012 11:36:45 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> Message-ID: On 5/4/12, John Curran wrote: > On May 4, 2012, at 10:24 AM, William Herrin wrote: >> But let me turn the question around: ARIN staff have been doing this >> for quite a while. How would staff handle the hospital as ISP scenario >> I posited? HIIPA says you don't get to look at the user data. It's the >> law. So what would data would staff seek for their audit instead? > > > Your hypothetical lacks sufficient detail to answer with certainty. It's > likely we would request customer reassignment data to verify utilization. > I am confident that sufficient information could be provided to ARIN under > NDA as needed which would not violate HIPPA's "protected health > information" > requirements, just as we have been able to work with parties with PII, > CPNI, > and related issues. Hi John, HIPAA restricts the use of 18 categories of information about a health care customer including: Names All geographical identifiers smaller than a state Phone numbers Email addresses By law, a U.S. hospital may only provide you with "de-identified data" about their customers. Even under NDA. But don't take my word for it, check with ARIN counsel. Regards, Bill -- 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 Fri May 4 13:12:59 2012 From: jcurran at arin.net (John Curran) Date: Fri, 4 May 2012 17:12:59 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> Message-ID: <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> On May 4, 2012, at 11:36 AM, William Herrin wrote: > Hi John, > > HIPAA restricts the use of 18 categories of information about a health > care customer including: > > Names > All geographical identifiers smaller than a state > Phone numbers > Email addresses > > By law, a U.S. hospital may only provide you with "de-identified data" > about their customers. Even under NDA. > > But don't take my word for it, check with ARIN counsel. Bill - I ran a highly secure data center for more than 5 years with nearly every compliance issue you can imagine (including HIPPA) and its application is not as facile as you outline above. I will not delve into every aspect of your hypothetical case and HIPPA, but will note that there are also statistical approaches that are allowed based on the removal of individually identifying information. As I noted in my reply, your hypothetical lacked sufficient information to more specifically answer. For example, if the network in question is actually a hospital (i.e. an end-user) as opposed to hospital service network, then under policy for end-user organizations we'd be asking for a brief description of each hospital subnet's purpose and the number of IP addresses projected to be used both short-term and within one year. If it really is a network which serves hospitals and medical institutions, we only need to understand their _organizational_ customers (i.e. medical service providers) IP usage not their individual patients IP assignments. I suppose you can contrive a hypothetical which is a cross-between these cases, but I think we'll deal with it when it actually arises. Thanks! /John John Curran President and CEO ARIN From bill at herrin.us Fri May 4 13:39:18 2012 From: bill at herrin.us (William Herrin) Date: Fri, 4 May 2012 13:39:18 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> Message-ID: On 5/4/12, John Curran wrote: > will note > that there are also statistical approaches that are allowed based on > the removal of individually identifying information. There you go. Statistical approaches based on the removal of individually identifying information. ARIN can't do this anywhere else it encounters /32 users because?? Regards, Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeffrey.lyon at blacklotus.net Fri May 4 13:44:13 2012 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 4 May 2012 13:44:13 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> Message-ID: On Fri, May 4, 2012 at 1:39 PM, William Herrin wrote: > On 5/4/12, John Curran wrote: >> ?will note >> ?that there are also statistical approaches that are allowed based on >> ?the removal of individually identifying information. > > There you go. Statistical approaches based on the removal of > individually identifying information. ARIN can't do this anywhere else > it encounters /32 users because?? > > Regards, > Bill > > > -- > 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. I think many agree that there are some cases where ARIN may need to become involved with PII matters, for instance in investigating potentially fraudulent resource requests. Nonetheless, we could still agree to significantly reduce the amount of PII that ARIN needs to see. For instance, we could agree that any resource request comprising no more than 40% /29 assignments which ARIN reasonably believes are in use (infrastructure justification vs. end user justification) then there would be no requirement to delve into who is actually using said assignments. -- Jeffrey A. Lyon, CISSP President | (757) 304-0668 http://www.blacklotus.net Black Lotus Communications From jcurran at arin.net Fri May 4 14:02:25 2012 From: jcurran at arin.net (John Curran) Date: Fri, 4 May 2012 18:02:25 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> Message-ID: <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> On May 4, 2012, at 1:39 PM, William Herrin wrote: > On 5/4/12, John Curran wrote: >> will note >> that there are also statistical approaches that are allowed based on >> the removal of individually identifying information. > > There you go. Statistical approaches based on the removal of > individually identifying information. ARIN can't do this anywhere else > it encounters /32 users because?? Bill - We ask for the customer assignment information necessary to verify the utilization. This is relatively straightforward and seems to work well for requesters. If you have very unusual constraints, you are welcome to propose an alternative for ARIN to verify this information for consideration, but please recognize that you are very likely to be told that your proposed alternative is insufficient for verification and we cannot consider those assignments for purposes of calculating utilization. If you would like ARIN to consider customer assignments as utilized without further verification, or consider proof of infrastructure to be sufficient validation for an assertion of IP utilization typical for such equipment, then please propose such as a change to number resource policy. Thanks! /John John Curran President and CEO ARIN From bill at herrin.us Fri May 4 14:33:45 2012 From: bill at herrin.us (William Herrin) Date: Fri, 4 May 2012 14:33:45 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> Message-ID: On 5/4/12, John Curran wrote: > On May 4, 2012, at 1:39 PM, William Herrin wrote: >> On 5/4/12, John Curran wrote: >>> will note >>> that there are also statistical approaches that are allowed based on >>> the removal of individually identifying information. >> >> There you go. Statistical approaches based on the removal of >> individually identifying information. ARIN can't do this anywhere else >> it encounters /32 users because?? > > We ask for the customer assignment information necessary to > verify the utilization. John, Now I'm confused. Which is it: you can find a way to work with statistical approaches instead of PII or you can't? > If you would like ARIN to consider customer assignments as > utilized without further verification, or consider proof of > infrastructure to be sufficient validation for an assertion > of IP utilization typical for such equipment, then please > propose such as a change to number resource policy. What I assert is that much of the community would like ARIN to verify utilization using best available approaches at its discretion -excluding- those which would have ARIN consume PII about downstream ISP customers holding fewer than 8 IP addresses. We have a whole policy development process available to find out whether that assertion is correct. However, since you have expressed a belief that my way of phrasing it violates the boundary between policy and process, I seek your assistance in phrasing this community requirement in a manner that is acceptable within the process. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From akara at tx-learn.net Fri May 4 14:35:40 2012 From: akara at tx-learn.net (Kara, Akbar) Date: Fri, 4 May 2012 13:35:40 -0500 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <01fa01cd297e$96685350$c338f9f0$@usc.edu> References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> <4FA2F446.6090605@burnttofu.net> <01fa01cd297e$96685350$c338f9f0$@usc.edu> Message-ID: <93C6FA14-1CF6-4E55-8C48-6CCDED6A25AB@tx-learn.net> Opposed. I concur with my colleague, Michael Sinatra. /ak TX-LEARN.net On May 3, 2012, at 5:46 PM, Celeste Anderson wrote: > +1 -- I am opposed to the policy as written for much the same reasons stated > by Michael. > > --celeste. > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Michael Sinatra > Sent: Thursday, May 03, 2012 2:11 PM > To: Jeffrey Lyon > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call > > On 5/3/12 1:08 PM, Jeffrey Lyon wrote: > >> What i'm attempting to argue is that this does not have to be a zero >> sum game. Just because this policy could benefit the management, bean >> counters, and marketing gurus of any given commercial enterprise does >> not mean that stewardship has been abandoned, that ARIN is becoming >> commercialized, or that we're somehow setting a bad precedent. Many >> could benefit substantially from the transferability of ASN's, its >> just unfortunately that the ultimate decision to strike down this >> proposal are not the same group of folks. >> >> Reiterating my position of "Strongly Support," > > When I vote in ARIN elections, I vote for people who understand and can > represent viewpoints other than their own. They can go beyond their > experiences and self-interest and understand the larger needs of the > community. It's the different between leadership and simple representation. > I'll note that many AC members that I have spoken to support this policy > despite the fact that it is not in their narrow interest to do so. > > Regarding the statement about PPML being predominantly engineers, I take > issue with the idea that engineers can't understand business or marketing > concepts. Not only do engineers need to worry about destabilizing this > important thing we are responsible for (i.e. the Internet), we have to > understand the business, economic, and political aspects of everything we > do. We need to understand the nexus of technology and policy. That's why > we follow PPML. (Moreover, PPML is not only engineers--there are business > people here, LE, etc.) > > Although the larger community has asked many times for use cases for this > policy, the very best we have come up with is to have numbers we can > remember. That and the bankruptcy issue (which I agree is compelling). > > The truth is, we really don't know what kind of negative effects we are > creating when we allow for this monetization of a number that has never been > of value in the past. No other RIR is currently entertaining such a > transfer policy, so we have no experience to go on. This is similar to the > excellent points that Heather Schiller made at ARIN 29. Given that we don't > know the effects of a wide-open ASN transfer policy, I agree with Christoph > that we should define the scope of the policy narrowly, to encompass the one > use case we can find. > > I am opposed to the policy as written, re-iterating my already-counted vote > at ARIN 29. > > michael > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public > Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Fri May 4 15:20:05 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 4 May 2012 12:20:05 -0700 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <1120503122722.977P-100000@Ives.egh.com> Message-ID: On May 4, 2012, at 4:45 AM, William Herrin wrote: > On Thu, May 3, 2012 at 12:27 PM, John Santos wrote: >> No one has presented *any* technical justification for this proposal. >> >> Opposed. > > On the one hand, I support the proposal. Whether or not there is a > reason to allow something is not the appropriate standard here. If we > can't show good cause why something should not be allowed then it > should be. I mean seriously, God forbid someone blows their nose > without first explaining to us why they want to. > I think that Tom has done a rather eloquent job of expressing at least one reason not to allow this. > > On Wed, May 2, 2012 at 3:32 PM, Alexander, Daniel > wrote: >> If I borrow some wording from the proposed PDP, when the AC has to >> determine consensus we have to determine whether the proposed change has >> substantially more support than opposition in the community active in the >> discussion. (56 PPML posts: 6 for, 3 against)(106 people in the room of >> the Public Policy Meeting: 27 for, 11 against) We also have to consider >> that the specific concerns expressed have been considered. This last part >> is one of the reasons I voted against this proposal. > > On the other hand, the AC paying attention to and _respecting_ > minority dissent within the community is long overdue. I don't > understand the dissent on this one. But since it exists, what's rush > to get the policy on the books? Let's talk about it some more first. > As part of that dissent, and as a frequent dissenter in AC decisions, I cannot abide your characterization of the AC here. I think the AC goes to great lengths to consider the dissenting minority opinion in ARIN policy debates. I agree that the AC does a relatively poor job of documenting that they did so in most cases. I cannot disclose details, but, I can assure you that AC meetings are not a rubber stamp process and that there is often spirited debate amongst us covering all sides prior to taking action on policy proposals. I do not believe that any AC actions have been the result of any form of bad faith or failure to represent the interests of the community. Owen From owen at delong.com Fri May 4 15:23:01 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 4 May 2012 12:23:01 -0700 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> <94E6B1D4-78C2-4895-90B3-34D326D40617@eyeconomics.com> <3513D82F-63DD-4EE6-AB81-285572F8A99C@eyeconomics.com> Message-ID: <2B1D7840-00BF-45E9-8C5B-5A8E0D6DCA29@delong.com> ASNs in toto, probably not. Desirable ASNs, Vanity ASNs, and 2-byte ASNs (for whatever absurd reason), YES. Absent this issue in any of those categories, can you think of a single reason this policy would be desirable? Owen On May 4, 2012, at 5:42 AM, Scott Leibrand wrote: > Tom, > > Can you elaborate on whether you see ASNs as a scarce resource, or whether you see conditions under which they might become scarce? From my perspective, the fact that there are 4 billion 4-byte ASNs, which (unlike IPv4 and IPv6) interoperate quite well with 2-byte ASNs, means that I don't see how your argument about cornering a market for a critical resource would apply in this situation. > > Thanks, > Scott > > On May 3, 2012, at 10:32 PM, Tom Vest wrote: > >> >> On May 3, 2012, at 11:23 PM, Jeffrey Lyon wrote: >> >>> On Thu, May 3, 2012 at 6:04 PM, Tom Vest wrote: >>>> >>>> On May 3, 2012, at 4:08 PM, Jeffrey Lyon wrote: >>>> >>>>> On Thu, May 3, 2012 at 3:45 PM, Blecker, Christoph >>>>> wrote: >>>>>> Simple version: I do not support this policy as written. >>>>>> >>>>>> Longer version: >>>>>> I have yet to see or fully understand a situation where a specified ASN transfer is either technically required or even preferable, outside of a network engineer just wanting a particular number. The way I currently understand it, the "vanity licence plate" metaphor that some have been using seems pretty accurate. This opens the door for assigning artificial value to a number that not many people outside network engineers know or should know about. I would support this change if there was a reasonable technical need behind it (and perhaps somebody can enlighten me). >>>>>> >>>>>> At ARIN XXIX, there was also been some talk around bankruptcy courts and not having a transfer policy around ASNs for that. Perhaps a more elegant solution would be to create a new 8.x policy to specifically address transferring resources from entities in bankruptcy, similar to the way 8.2 addresses M&As. That way, ARIN has more guidance to what the community thinks, and judges involved have specific recommendations from us in how the community views these resources. >>>>>> >>>>>> Overall, I think more discussion is needed. >>>>>> >>>>>> Cheers, >>>>>> Christoph >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >>>>>> Sent: April-30-12 10:19 AM >>>>>> To: arin-ppml at arin.net >>>>>> Subject: [arin-ppml] ARIN-2012-3: ASN 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-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. >>>>>> _______________________________________________ >>>>>> 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. >>>>> >>>>> The problem with many proposals, this one especially, is that every >>>>> situation is always looked at from the perspective of "is this >>>>> technically required." I would argue that many look at every situation >>>>> from the perspective of "would I benefit from this?" To be fair, most >>>>> here do align "I benefit" with stewardship, but herein lies the >>>>> problem. >>>>> >>>>> PPML, policy meetings, etc. are highly dominated by "old school" >>>>> engineers. I vote at ARIN elections, and consistently see speeches >>>>> that detail how long each candidate has been supporting stewardship, >>>>> how they helped pioneer the internet, and so forth. That's great, we >>>>> love you for it and you command much respect from your peers. The >>>>> problem that we now face in 2012 is that the community is >>>>> substantially larger and more diverse than the representation within >>>>> the ARIN policy community. Some quick observations: >>>>> >>>>> - PPML is predominately engineers, most of whom are not involved in >>>>> financial decision making for their organizations (or are from >>>>> non-profits) >>>>> - Attendees at ARIN meetings are predominately the same folks. >>>>> - Given these observations, i'm willing to assume that those who >>>>> actually vote at ARIN elections are mostly the same crew of old school >>>>> policy makers. >>>>> >>>>> What i'm attempting to argue is that this does not have to be a zero >>>>> sum game. Just because this policy could benefit the management, bean >>>>> counters, and marketing gurus of any given commercial enterprise does >>>>> not mean that stewardship has been abandoned, that ARIN is becoming >>>>> commercialized, or that we're somehow setting a bad precedent. >>>> >>>> In theory, stewardship interests and "bean counting" interests might indeed be the same; in practice, they rarely are. >>>> While I don't place much stock in the distinctions that you make here, they do help to illuminate the hole in this argument. >>>> Stewardship requires a balancing of interests not only along the continuum of old-school engineers, new-age bean counters, and other diverse (but seemingly silent/invisible) stakeholder groups in the present-day ARIN policy community. It also entails balancing interests along a complete different dimension -- i.e., the one that separates *current* stewardship policy stakeholders (a.k.a. "incumbents") and *future* community members (a.k.a. prospective "new entrants"). On a good day it's just possible, with significant time and attention, to come up with stewardship policy solutions that satisfy that balancing requirement in both dimensions... or at least it is when the stakeholder community(s) are defined in explicitly technical terms. Throw "bean counter" interests into that mix, however, and that balancing exercise becomes impossible. >>>> >>>> If you have any doubts about this, I suggest that you try to imagine how you might feel if ASN privatization had taken place back in 1993-1994, before your network existed (or transitioned to BGP4/IDR). Now imagine that your best option for obtaining an ASN was your least favorite upstream provider. For extra points, you could also try imagining that you live somewhere where the total number of reachable upstream providers is between 0-2. >>>> >>>> If you can imagine yourself and/or your own "bean counters" being indifferent between that scenario -- or any other other that you can come up with -- and the current scenario in which you are able to obtain an ASN on neutral, technically defined, non-adversarial terms, then I encourage you to share it with the list; I will maintain an open mind. >>>> >>>> Thanks, >>>> >>>> TV >>>> >>>> P.S. IMO, that overlooked, forward-looking aspect of the stakeholder mandate is also one of the most important distinguishing features that separates what routing and addressing industry members do in this domain, individually and collectively, from the sort of activities that tend to attract very unfriendly (read: "unprofitable") attention from DOJ and other competition authorities. It's also the one thing that distinguishes what policy community members have chosen to do with respect to the disposition of IPv4 from what former Soviet politburo members chose to do with respect to the disposition of Russia's "public" assets back in 1991-1992. Please think *very* carefully abandoning that part of our mandate. >>>> >>>> >>>> _______________________________________________ >>>> 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. >>> >>> Tom, >>> >>> I am not tracking on your example pertaining to ASN privatization. I'm >>> in support of organizations being able to transfer their ASN >>> resources, not in support of entities being required to petition >>> telecom oligopolies to obtain resources. I am strictly in support of >>> proposals that give our constituents more freedoms, not less. >>> >>> IT/IS, management, and accounting are closely related, often >>> intersecting disciplines. I strongly believe that the opinions stated >>> by those opposed in this discussion thread are those of the former, >>> not of the latter. All 3 (and probably some others) are ARIN >>> stakeholders that must be represented. This is not to say that the >>> needs of management and accountants must completely supersede those of >>> IT/IS, but rather that those needs can be addressed in a manner that >>> does not unduly burden others. >> >> Hi Jeffrey, >> >> For the record, my own policy views are based on personal experience that straddles all three of the disciplines you cite, and is probably influenced more by my past "bean counting" work than anything else -- so you can nix that theory. I'm not worried about things that might happen, but rather about things that *will* happen, because they always happen when very clever people with specialized expertise encounter obscure but potentially lucrative strategic (technical/regulatory) arbitrage opportunities. What invariably happens is they "go for it" -- always -- even in cases where the loophole exploiters themselves are fully aware that what they're trying to do could (and likely will) have very far-reaching adverse consequences. They ignore such risks because doing so will pay off for their employers, at least in the short-term; because it'll be good for their own careers, reputations, and personal fortunes; because the competitive marketplace assures that if they don't go fo > r >> it first, someone else will, eventually; and ultimately because it's great fun to be (or at least play at) master of the universe. Call that the "anti-stewardship" orientation. For better or worse, that's the role that many of us play (or have played at some point) in our professional lives, outside of this forum. And that's precisely why, IMO, we would all do well to be a little less coy about the realities of the marketplace in this forum. Because in the end, the best way to minimize any future temptation that you or I might face to go "rogue trader," and also to minimize the risk/harm that we and everyone else *will* face if enough of y/our competitors should succumb to such temptations, is to make sure that the exploitable loopholes that give rise to such temptations are closed, or at least made less attractive and kept under constant, close scrutiny. >> >> As for the claim that an ASN transfer policy would provide more freedom for stakeholders, that again completely ignores the temporal dimension that distinguishes "stewardship" from blind faith in markets. Your liberty to become a commercial ASN broker today would be purchased at the expense of future ASN seekers, who will be deprived of the opportunity that you and every other "incumbent" number resource stakeholder has enjoyed to date -- namely, the opportunity to obtain number resources on non-adversarial, technical needs-based terms from a non-competitor. >> >> I apologize if my previous examples were unclear, but let me try one more time, using the above argument. Say you currently work in the kind of environment where "good ideas" for cutting costs and/or increasing revenues are recognized and rewarded -- and where the most highly prized ideas of all are those that can be expected to pay off for a long long time, e.g., because they are opaque to competitors and third parties in general. The actual job you do might be in an IT/IS/engineering department, or in "business development," or in executive management. It really doesn't matter which: you're a "bean counter" of some kind, regardless of your actual title. From that perspective, please choose which of the three business conditions you would prefer: >> >> 1. I possess surplus reserves of a critical resource that my current competitors must obtain in order to grow, and without which prospective future competitors cannot even enter my market. They don't necessarily have to get the critical resource from me, but if they don't their only alternative is to get it from another market actor that has appx. the same strategic/competitive interests that I have with respect to this particular market. >> >> 2. I do not have enough of the critical resource to realize my Internet operations-business potential, and my only options are to try to obtain the resource from a current competitor, or from some other entity that knows that selling that resource to me will effectively make me a potential future competitor. Unless/until I obtain (more of) that critical resource, I cannot enter the Internet operations business/market and/or grow my business to its full potential. >> >> 3. I do not have enough of the critical resource, but if I can credibly demonstrate that my ability to enter the market and/or grow is contingent (only) on possession of that critical resource, then I can always obtain what I "need" on neutral, transparent, non-preferential terms from a non-competitor. >> >> You are free to choose (1), but only if you can find, say, 10 other current stakeholders that are willing to opt out of (2) in favor of (3). And even if you can manage that, you'll still need to come up with an argument that would persuasive enough to convince future stakeholders that their fortunes would be improved by being your (or someone else's) customer for ASNs, as opposed to being no ones customer for ASNs. >> >> I know it can be tempting to imagine that this would be a perfectly reasonable arrangement, which is why I encourage you to go through the whole hypothetical scenario once more, but this time imagining yourself in the same bean counter role, albeit a decade after all commercially viable ASNs have been privatized. This time you get no choice; you're stuck with (3). >> >> If you are truly indifferent between those two alternatives -- i.e., your bean counting aspirations would be equally fulfilled by status (1) or status (3), then you are to be commended for your genuine, consistent commitment to free market principles. I'm sure that ARIN will happily accept the return of your current ASNs, but no doubt the ASN transfer market will provide for whatever is needed thereafter. >> >> In fact, if everyone in favor of 2012-3 is willing to do the same, and abandon all claim to 100% of the ASNs currently in their possession, I just might be persuaded to support this policy. >> >> Any takers? >> >> TV >> >> >> _______________________________________________ >> 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 jcurran at arin.net Fri May 4 15:49:58 2012 From: jcurran at arin.net (John Curran) Date: Fri, 4 May 2012 19:49:58 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> Message-ID: <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> On May 4, 2012, at 2:33 PM, William Herrin wrote: > Now I'm confused. Which is it: you can find a way to work with > statistical approaches instead of PII or you can't? Bill - I really don't know either way as the situation hasn't arose. We process thousands of requests each year, but if that particular weird hybrid network of an ISP for hospitals (but with individual patient/customer assignments) came in, we'd request the reassignment information. Unless there was a strong alternative proposed by the ISP that provided for realistic verification of utilization, I'd need to say "no" based on current policy. If there was very good alternative proposed for this one situation which still provided us sufficient confidence in the network utilization, then we'd try to accommodate it in good faith, but I have no idea how to make general policy based on something that hasn't occurred yet. >> If you would like ARIN to consider customer assignments as >> utilized without further verification, or consider proof of >> infrastructure to be sufficient validation for an assertion >> of IP utilization typical for such equipment, then please >> propose such as a change to number resource policy. > > What I assert is that much of the community would like ARIN to verify > utilization using best available approaches at its discretion > -excluding- those which would have ARIN consume PII about downstream > ISP customers holding fewer than 8 IP addresses. If that's the case, you should then propose policy which precludes ARIN from requesting that information. It's simple, clear, and can be discussed by the community in a straightforward manner. Instead, you have proposed a process change that ARIN can request this information, but only as last resort. Given that requesting this information is the typical method for verifying utilization of networks consisting of customer reassignments, I've asked you several times what alternatives you propose for verifying the utilization of these networks. Those coming in for address space do not seem to have a problem providing customer reassignment information, and this is running code. Under your proposed process change, I'm not certain what you want ARIN to ask for instead, and the discussion on the list has not made that any clearer. > We have a whole policy development process available to find out > whether that assertion is correct. However, since you have expressed a > belief that my way of phrasing it violates the boundary between policy > and process, I seek your assistance in phrasing this community > requirement in a manner that is acceptable within the process. You should propose policy which precludes ARIN from requesting such information if that is what you desire. We would then take customer redelegations as valid as presented, and that should address your concern. The only other option that has been clearly defined would be for ARIN not ask for individual reassignments to customers but instead to consider proof of infrastructure to be sufficient validation for an assertion of IP utilization typical for such equipment. This is appears to be a workable policy change to address your concern. It would be helpful (as was alluded to by another participant on the list) to make a proposal which changes policy in either of the options above if that's what is actually intended. Thanks! /John John Curran President and CEO ARIN From jeffrey.lyon at blacklotus.net Fri May 4 16:11:13 2012 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 4 May 2012 16:11:13 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <2B1D7840-00BF-45E9-8C5B-5A8E0D6DCA29@delong.com> References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> <94E6B1D4-78C2-4895-90B3-34D326D40617@eyeconomics.com> <3513D82F-63DD-4EE6-AB81-285572F8A99C@eyeconomics.com> <2B1D7840-00BF-45E9-8C5B-5A8E0D6DCA29@delong.com> Message-ID: First off, sorry for the top post. My mobile device is not compliant with ppml norms. As a practical matter, only 2 bit ASNs would typically be transferred, but I don't see any reason to restrict transferability of any ASN. Thanks, Jeff On May 4, 2012 3:24 PM, "Owen DeLong" wrote: > ASNs in toto, probably not. > > Desirable ASNs, Vanity ASNs, and 2-byte ASNs (for whatever absurd reason), > YES. > > Absent this issue in any of those categories, can you think of a single > reason this policy would be desirable? > > Owen > > On May 4, 2012, at 5:42 AM, Scott Leibrand wrote: > > > Tom, > > > > Can you elaborate on whether you see ASNs as a scarce resource, or > whether you see conditions under which they might become scarce? From my > perspective, the fact that there are 4 billion 4-byte ASNs, which (unlike > IPv4 and IPv6) interoperate quite well with 2-byte ASNs, means that I don't > see how your argument about cornering a market for a critical resource > would apply in this situation. > > > > Thanks, > > Scott > > > > On May 3, 2012, at 10:32 PM, Tom Vest wrote: > > > >> > >> On May 3, 2012, at 11:23 PM, Jeffrey Lyon wrote: > >> > >>> On Thu, May 3, 2012 at 6:04 PM, Tom Vest > wrote: > >>>> > >>>> On May 3, 2012, at 4:08 PM, Jeffrey Lyon wrote: > >>>> > >>>>> On Thu, May 3, 2012 at 3:45 PM, Blecker, Christoph > >>>>> wrote: > >>>>>> Simple version: I do not support this policy as written. > >>>>>> > >>>>>> Longer version: > >>>>>> I have yet to see or fully understand a situation where a specified > ASN transfer is either technically required or even preferable, outside of > a network engineer just wanting a particular number. The way I currently > understand it, the "vanity licence plate" metaphor that some have been > using seems pretty accurate. This opens the door for assigning artificial > value to a number that not many people outside network engineers know or > should know about. I would support this change if there was a reasonable > technical need behind it (and perhaps somebody can enlighten me). > >>>>>> > >>>>>> At ARIN XXIX, there was also been some talk around bankruptcy > courts and not having a transfer policy around ASNs for that. Perhaps a > more elegant solution would be to create a new 8.x policy to specifically > address transferring resources from entities in bankruptcy, similar to the > way 8.2 addresses M&As. That way, ARIN has more guidance to what the > community thinks, and judges involved have specific recommendations from us > in how the community views these resources. > >>>>>> > >>>>>> Overall, I think more discussion is needed. > >>>>>> > >>>>>> Cheers, > >>>>>> Christoph > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of ARIN > >>>>>> Sent: April-30-12 10:19 AM > >>>>>> To: arin-ppml at arin.net > >>>>>> Subject: [arin-ppml] ARIN-2012-3: ASN 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-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. > >>>>>> _______________________________________________ > >>>>>> 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. > >>>>> > >>>>> The problem with many proposals, this one especially, is that every > >>>>> situation is always looked at from the perspective of "is this > >>>>> technically required." I would argue that many look at every > situation > >>>>> from the perspective of "would I benefit from this?" To be fair, most > >>>>> here do align "I benefit" with stewardship, but herein lies the > >>>>> problem. > >>>>> > >>>>> PPML, policy meetings, etc. are highly dominated by "old school" > >>>>> engineers. I vote at ARIN elections, and consistently see speeches > >>>>> that detail how long each candidate has been supporting stewardship, > >>>>> how they helped pioneer the internet, and so forth. That's great, we > >>>>> love you for it and you command much respect from your peers. The > >>>>> problem that we now face in 2012 is that the community is > >>>>> substantially larger and more diverse than the representation within > >>>>> the ARIN policy community. Some quick observations: > >>>>> > >>>>> - PPML is predominately engineers, most of whom are not involved in > >>>>> financial decision making for their organizations (or are from > >>>>> non-profits) > >>>>> - Attendees at ARIN meetings are predominately the same folks. > >>>>> - Given these observations, i'm willing to assume that those who > >>>>> actually vote at ARIN elections are mostly the same crew of old > school > >>>>> policy makers. > >>>>> > >>>>> What i'm attempting to argue is that this does not have to be a zero > >>>>> sum game. Just because this policy could benefit the management, bean > >>>>> counters, and marketing gurus of any given commercial enterprise does > >>>>> not mean that stewardship has been abandoned, that ARIN is becoming > >>>>> commercialized, or that we're somehow setting a bad precedent. > >>>> > >>>> In theory, stewardship interests and "bean counting" interests might > indeed be the same; in practice, they rarely are. > >>>> While I don't place much stock in the distinctions that you make > here, they do help to illuminate the hole in this argument. > >>>> Stewardship requires a balancing of interests not only along the > continuum of old-school engineers, new-age bean counters, and other diverse > (but seemingly silent/invisible) stakeholder groups in the present-day ARIN > policy community. It also entails balancing interests along a complete > different dimension -- i.e., the one that separates *current* stewardship > policy stakeholders (a.k.a. "incumbents") and *future* community members > (a.k.a. prospective "new entrants"). On a good day it's just possible, with > significant time and attention, to come up with stewardship policy > solutions that satisfy that balancing requirement in both dimensions... or > at least it is when the stakeholder community(s) are defined in explicitly > technical terms. Throw "bean counter" interests into that mix, however, and > that balancing exercise becomes impossible. > >>>> > >>>> If you have any doubts about this, I suggest that you try to imagine > how you might feel if ASN privatization had taken place back in 1993-1994, > before your network existed (or transitioned to BGP4/IDR). Now imagine that > your best option for obtaining an ASN was your least favorite upstream > provider. For extra points, you could also try imagining that you live > somewhere where the total number of reachable upstream providers is between > 0-2. > >>>> > >>>> If you can imagine yourself and/or your own "bean counters" being > indifferent between that scenario -- or any other other that you can come > up with -- and the current scenario in which you are able to obtain an ASN > on neutral, technically defined, non-adversarial terms, then I encourage > you to share it with the list; I will maintain an open mind. > >>>> > >>>> Thanks, > >>>> > >>>> TV > >>>> > >>>> P.S. IMO, that overlooked, forward-looking aspect of the stakeholder > mandate is also one of the most important distinguishing features that > separates what routing and addressing industry members do in this domain, > individually and collectively, from the sort of activities that tend to > attract very unfriendly (read: "unprofitable") attention from DOJ and other > competition authorities. It's also the one thing that distinguishes what > policy community members have chosen to do with respect to the disposition > of IPv4 from what former Soviet politburo members chose to do with respect > to the disposition of Russia's "public" assets back in 1991-1992. Please > think *very* carefully abandoning that part of our mandate. > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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. > >>> > >>> Tom, > >>> > >>> I am not tracking on your example pertaining to ASN privatization. I'm > >>> in support of organizations being able to transfer their ASN > >>> resources, not in support of entities being required to petition > >>> telecom oligopolies to obtain resources. I am strictly in support of > >>> proposals that give our constituents more freedoms, not less. > >>> > >>> IT/IS, management, and accounting are closely related, often > >>> intersecting disciplines. I strongly believe that the opinions stated > >>> by those opposed in this discussion thread are those of the former, > >>> not of the latter. All 3 (and probably some others) are ARIN > >>> stakeholders that must be represented. This is not to say that the > >>> needs of management and accountants must completely supersede those of > >>> IT/IS, but rather that those needs can be addressed in a manner that > >>> does not unduly burden others. > >> > >> Hi Jeffrey, > >> > >> For the record, my own policy views are based on personal experience > that straddles all three of the disciplines you cite, and is probably > influenced more by my past "bean counting" work than anything else -- so > you can nix that theory. I'm not worried about things that might happen, > but rather about things that *will* happen, because they always happen when > very clever people with specialized expertise encounter obscure but > potentially lucrative strategic (technical/regulatory) arbitrage > opportunities. What invariably happens is they "go for it" -- always -- > even in cases where the loophole exploiters themselves are fully aware that > what they're trying to do could (and likely will) have very far-reaching > adverse consequences. They ignore such risks because doing so will pay off > for their employers, at least in the short-term; because it'll be good for > their own careers, reputations, and personal fortunes; because the > competitive marketplace assures that if they don't go f > o > > r > >> it first, someone else will, eventually; and ultimately because it's > great fun to be (or at least play at) master of the universe. Call that the > "anti-stewardship" orientation. For better or worse, that's the role that > many of us play (or have played at some point) in our professional lives, > outside of this forum. And that's precisely why, IMO, we would all do well > to be a little less coy about the realities of the marketplace in this > forum. Because in the end, the best way to minimize any future temptation > that you or I might face to go "rogue trader," and also to minimize the > risk/harm that we and everyone else *will* face if enough of y/our > competitors should succumb to such temptations, is to make sure that the > exploitable loopholes that give rise to such temptations are closed, or at > least made less attractive and kept under constant, close scrutiny. > >> > >> As for the claim that an ASN transfer policy would provide more freedom > for stakeholders, that again completely ignores the temporal dimension that > distinguishes "stewardship" from blind faith in markets. Your liberty to > become a commercial ASN broker today would be purchased at the expense of > future ASN seekers, who will be deprived of the opportunity that you and > every other "incumbent" number resource stakeholder has enjoyed to date -- > namely, the opportunity to obtain number resources on non-adversarial, > technical needs-based terms from a non-competitor. > >> > >> I apologize if my previous examples were unclear, but let me try one > more time, using the above argument. Say you currently work in the kind of > environment where "good ideas" for cutting costs and/or increasing revenues > are recognized and rewarded -- and where the most highly prized ideas of > all are those that can be expected to pay off for a long long time, e.g., > because they are opaque to competitors and third parties in general. The > actual job you do might be in an IT/IS/engineering department, or in > "business development," or in executive management. It really doesn't > matter which: you're a "bean counter" of some kind, regardless of your > actual title. From that perspective, please choose which of the three > business conditions you would prefer: > >> > >> 1. I possess surplus reserves of a critical resource that my current > competitors must obtain in order to grow, and without which prospective > future competitors cannot even enter my market. They don't necessarily have > to get the critical resource from me, but if they don't their only > alternative is to get it from another market actor that has appx. the same > strategic/competitive interests that I have with respect to this particular > market. > >> > >> 2. I do not have enough of the critical resource to realize my Internet > operations-business potential, and my only options are to try to obtain the > resource from a current competitor, or from some other entity that knows > that selling that resource to me will effectively make me a potential > future competitor. Unless/until I obtain (more of) that critical resource, > I cannot enter the Internet operations business/market and/or grow my > business to its full potential. > >> > >> 3. I do not have enough of the critical resource, but if I can credibly > demonstrate that my ability to enter the market and/or grow is contingent > (only) on possession of that critical resource, then I can always obtain > what I "need" on neutral, transparent, non-preferential terms from a > non-competitor. > >> > >> You are free to choose (1), but only if you can find, say, 10 other > current stakeholders that are willing to opt out of (2) in favor of (3). > And even if you can manage that, you'll still need to come up with an > argument that would persuasive enough to convince future stakeholders that > their fortunes would be improved by being your (or someone else's) customer > for ASNs, as opposed to being no ones customer for ASNs. > >> > >> I know it can be tempting to imagine that this would be a perfectly > reasonable arrangement, which is why I encourage you to go through the > whole hypothetical scenario once more, but this time imagining yourself in > the same bean counter role, albeit a decade after all commercially viable > ASNs have been privatized. This time you get no choice; you're stuck with > (3). > >> > >> If you are truly indifferent between those two alternatives -- i.e., > your bean counting aspirations would be equally fulfilled by status (1) or > status (3), then you are to be commended for your genuine, consistent > commitment to free market principles. I'm sure that ARIN will happily > accept the return of your current ASNs, but no doubt the ASN transfer > market will provide for whatever is needed thereafter. > >> > >> In fact, if everyone in favor of 2012-3 is willing to do the same, and > abandon all claim to 100% of the ASNs currently in their possession, I just > might be persuaded to support this policy. > >> > >> Any takers? > >> > >> TV > >> > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lar at mwtcorp.net Fri May 4 16:23:22 2012 From: lar at mwtcorp.net (Larry Ash) Date: Fri, 04 May 2012 14:23:22 -0600 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <2B1D7840-00BF-45E9-8C5B-5A8E0D6DCA29@delong.com> References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> <94E6B1D4-78C2-4895-90B3-34D326D40617@eyeconomics.com> <3513D82F-63DD-4EE6-AB81-285572F8A99C@eyeconomics.com> <2B1D7840-00BF-45E9-8C5B-5A8E0D6DCA29@delong.com> Message-ID: Oppose. ASN's can and have been transfered via merger and acquisition of assets. Policy can be modified to add bankruptcy however I'm not in favor if the ASN is separated from the related network assets that require that ASN for ongoing operation. I see no value or reason to attempt to create a market in ASN's. P.S. My degree is in Business Administration. I do understand Accounting, Management and Marketing. >>>>>>> >>>>>>> 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. >>>>>>> _______________________________________________ Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From ppml at rsuc.gweep.net Fri May 4 16:24:40 2012 From: ppml at rsuc.gweep.net (Joe Provo) Date: Fri, 4 May 2012 16:24:40 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <93C6FA14-1CF6-4E55-8C48-6CCDED6A25AB@tx-learn.net> References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> <4FA2F446.6090605@burnttofu.net> <01fa01cd297e$96685350$c338f9f0$@usc.edu> <93C6FA14-1CF6-4E55-8C48-6CCDED6A25AB@tx-learn.net> Message-ID: <20120504202440.GA92975@gweep.net> On Fri, May 04, 2012 at 01:35:40PM -0500, Kara, Akbar wrote: > Opposed. I concur with my colleague, Michael Sinatra. > > /ak > TX-LEARN.net > > > On May 3, 2012, at 5:46 PM, Celeste Anderson wrote: > > > +1 -- I am opposed to the policy as written for much the same reasons stated > > by Michael. > > > > --celeste. As before, continue to be opposed based on the lack of any rationale beyomd "because we can". -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From snowhorn at gmail.com Fri May 4 16:31:39 2012 From: snowhorn at gmail.com (Joshua Snowhorn) Date: Fri, 4 May 2012 15:31:39 -0500 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> <94E6B1D4-78C2-4895-90B3-34D326D40617@eyeconomics.com> <3513D82F-63DD-4EE6-AB81-285572F8A99C@eyeconomics.com> <2B1D7840-00BF-45E9-8C5B-5A8E0D6DCA29@delong.com> Message-ID: <041C4D2C-89D5-441D-A3ED-3C545138AAF2@gmail.com> On May 4, 2012, at 3:23 PM, Larry Ash wrote: > Oppose. > > ASN's can and have been transfered via merger and acquisition of assets. Policy > can be modified to add bankruptcy however I'm not in favor if the ASN is separated > from the related network assets that require that ASN for ongoing operation. > > I see no value or reason to attempt to create a market in ASN's. > > P.S. My degree is in Business Administration. I do understand Accounting, Management > and Marketing. Strongly support. We are defining a transfer process outside of outright acquisition of a company. There are certainly instances where companies have no need for an ASN that they may already own. They can dump it back in the pool or they can transfer it via a defined process...with or without monetary exchange of funds, if we allow transfers. If you limit this to just bankruptcy you complicate things with more language defining an outright acquisition of a bankrupt entity to gain that ASN asset or just an extricated asset from the bankrupt entity...messy. Josh > >>>>>>>> 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. >>>>>>>> _______________________________________________ > > > Larry Ash > Network Administrator > Mountain West Telephone > 123 W 1st St. > Casper, WY 82601 > Office 307 233-8387 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at herrin.us Fri May 4 17:19:23 2012 From: bill at herrin.us (William Herrin) Date: Fri, 4 May 2012 17:19:23 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> 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: 2.0 4. Date: 5/4/2012 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: ARIN is precluded from from requesting Personally Identifiable Information (PII) about ISP customers holding fewer than 8 IP addresses. 8. Rationale: Per http://lists.arin.net/pipermail/arin-ppml/2012-April/024523.html , ARIN considers the /29 border for identifying customers called out seven distinct times in the NRPM to apply only to publication of such records. Author contends that excluding law enforcement action to which ARIN is generally not party, the identities of such small consumers of IP addresses are a private matter between the ISP and its customer. Per http://lists.arin.net/pipermail/arin-ppml/2012-May/024697.html , it is not possible for an NRPM policy to direct that a given ARIN behavior be undertaken only as a last resort. So, this version of the proposal simply prohibits ARIN from collecting PII about sub-/29 registrants instead of authorizing it only as a last resort. 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 tvest at eyeconomics.com Fri May 4 17:29:20 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 4 May 2012 17:29:20 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA2E597@S-ITSV-MBX01P.ead.ubc.ca> <94E6B1D4-78C2-4895-90B3-34D326D40617@eyeconomics.com> <3513D82F-63DD-4EE6-AB81-285572F8A99C@eyeconomics.com> Message-ID: <7AF28AF3-440A-4A50-819D-1E8D314138ED@eyeconomics.com> On May 4, 2012, at 8:42 AM, Scott Leibrand wrote: > Tom, > > Can you elaborate on whether you see ASNs as a scarce resource, or whether you see conditions under which they might become scarce? From my perspective, the fact that there are 4 billion 4-byte ASNs, which (unlike IPv4 and IPv6) interoperate quite well with 2-byte ASNs, means that I don't see how your argument about cornering a market for a critical resource would apply in this situation. > > Thanks, > Scott Hi Scott, I think it would be best for you to direct that question to someone who actually thinks, or has at least argued, that the possibility of someone "cornering the market" is the greatest or only risk associated with privatizing ASNs. I could imagine what they might say, but since I don't personally believe that to be the case, and I have never in fact argued from that position (while I have actually tried to correct the same spurious association on this very list, and NANOG/new, and NANOG/old, on numerous occasions), I think I'll let someone else take a turn arguing on behalf of that apparently undying straw man. If, as you suggest, four-byte ASNs interoperate quite easily with two-byte ASNs, then it doesn't sound like there's any particularly compelling need to introduce yet another scarcity-oriented distribution mechanism *at this particular moment*, when we're already facing a very profound, risky, and controversy-prone global transition in business and operational practices related to IP addressing. Choosing to add yet another layer of uncertainty/opacity/friction on top of the uncertainty/opacity/frictions that we've already embraced with IPv4 markets, which will themselves only compound the IPv6-related uncertainty/opacity/frictions that were perhaps unavoidable, is IMO a really bad, bordering-on-reckless idea. That said, I can think of at least two ways that many/most concerns about the risks associated with ASN privatization could be assuaged by evolving facts on the ground, possibly in the near future: (1) Once it becomes clear that (a) established, two-byte ASN-holding operators in every service segment (including consumer access) have started to consistently accept four-byte ASNs, and put them into production rather than returning them for ASN16s, and (b) once it becomes clear that established, two-byte ASN-holding operators of all stripes are consistently offering non-discriminatory "most-favored-ASN-format" treatment to aspiring ASN32-based access/transit customers and peers, then we'll have some basis for confidence that four-byte ASNs are unlikely to be "rejected by the market." Only at that point will we actually *know* what can we only assume at this point, i.e., that there really are "4 billion [unallocated and operationally useful] ASNs, which (unlike IPv4 and IPv6) interoperate quite well," and thus that there is no broad risk of ASN-related scarcity/market manipulation, etc. [Note: alternately, we could simply wait until ASN32s originate the majority of traffic/routes, and the commercial practices of ASN16-only holdouts become irrelevant -- but that would obviously take much longer]. (2) Once it becomes clear that (a) established, IPv4-holding operators in every service segment (including consumer access) have started to consistently embrace and integrate IPv6, and (b) once it becomes clear that established operators of all stripes are consistently offering non-discriminatory "most-favored-address-format" treatment to aspiring IPv6-only access/transit customers and peers, then we'll be justified in assuming that IPv6 is unlikely to be "rejected by the market." At that point we'll actually have some basis for believing what at this point can we only hope, i.e., that the TCP/IP-based routing and addressing industry is, in fact, the first such system of its kind in human history to be highly resistant, or maybe even immune, to the sort of systemic (e.g., "adverse selection") problems that have caused all other, similar industries in recorded human history to (severely to catastrophically) fail on a semi-regular basis. If you are right and my concerns are unfounded, then it seems like at least one if not both of those conditions should be satisfied in the relatively near future. IMO, once at least one of those milestones has been passed, *that* would be the right time to take up an ASN transfer proposal. Not before. Conversely, if neither happens anytime soon, then ISTM that it would be prudent to reconsider whether the stated and unstated assumptions underlying the arguments for ASN transfers are in fact valid. TV > On May 3, 2012, at 10:32 PM, Tom Vest wrote: > >> >> On May 3, 2012, at 11:23 PM, Jeffrey Lyon wrote: >> >>> On Thu, May 3, 2012 at 6:04 PM, Tom Vest wrote: >>>> >>>> On May 3, 2012, at 4:08 PM, Jeffrey Lyon wrote: >>>> >>>>> On Thu, May 3, 2012 at 3:45 PM, Blecker, Christoph >>>>> wrote: >>>>>> Simple version: I do not support this policy as written. >>>>>> >>>>>> Longer version: >>>>>> I have yet to see or fully understand a situation where a specified ASN transfer is either technically required or even preferable, outside of a network engineer just wanting a particular number. The way I currently understand it, the "vanity licence plate" metaphor that some have been using seems pretty accurate. This opens the door for assigning artificial value to a number that not many people outside network engineers know or should know about. I would support this change if there was a reasonable technical need behind it (and perhaps somebody can enlighten me). >>>>>> >>>>>> At ARIN XXIX, there was also been some talk around bankruptcy courts and not having a transfer policy around ASNs for that. Perhaps a more elegant solution would be to create a new 8.x policy to specifically address transferring resources from entities in bankruptcy, similar to the way 8.2 addresses M&As. That way, ARIN has more guidance to what the community thinks, and judges involved have specific recommendations from us in how the community views these resources. >>>>>> >>>>>> Overall, I think more discussion is needed. >>>>>> >>>>>> Cheers, >>>>>> Christoph >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >>>>>> Sent: April-30-12 10:19 AM >>>>>> To: arin-ppml at arin.net >>>>>> Subject: [arin-ppml] ARIN-2012-3: ASN 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-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. >>>>>> _______________________________________________ >>>>>> 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. >>>>> >>>>> The problem with many proposals, this one especially, is that every >>>>> situation is always looked at from the perspective of "is this >>>>> technically required." I would argue that many look at every situation >>>>> from the perspective of "would I benefit from this?" To be fair, most >>>>> here do align "I benefit" with stewardship, but herein lies the >>>>> problem. >>>>> >>>>> PPML, policy meetings, etc. are highly dominated by "old school" >>>>> engineers. I vote at ARIN elections, and consistently see speeches >>>>> that detail how long each candidate has been supporting stewardship, >>>>> how they helped pioneer the internet, and so forth. That's great, we >>>>> love you for it and you command much respect from your peers. The >>>>> problem that we now face in 2012 is that the community is >>>>> substantially larger and more diverse than the representation within >>>>> the ARIN policy community. Some quick observations: >>>>> >>>>> - PPML is predominately engineers, most of whom are not involved in >>>>> financial decision making for their organizations (or are from >>>>> non-profits) >>>>> - Attendees at ARIN meetings are predominately the same folks. >>>>> - Given these observations, i'm willing to assume that those who >>>>> actually vote at ARIN elections are mostly the same crew of old school >>>>> policy makers. >>>>> >>>>> What i'm attempting to argue is that this does not have to be a zero >>>>> sum game. Just because this policy could benefit the management, bean >>>>> counters, and marketing gurus of any given commercial enterprise does >>>>> not mean that stewardship has been abandoned, that ARIN is becoming >>>>> commercialized, or that we're somehow setting a bad precedent. >>>> >>>> In theory, stewardship interests and "bean counting" interests might indeed be the same; in practice, they rarely are. >>>> While I don't place much stock in the distinctions that you make here, they do help to illuminate the hole in this argument. >>>> Stewardship requires a balancing of interests not only along the continuum of old-school engineers, new-age bean counters, and other diverse (but seemingly silent/invisible) stakeholder groups in the present-day ARIN policy community. It also entails balancing interests along a complete different dimension -- i.e., the one that separates *current* stewardship policy stakeholders (a.k.a. "incumbents") and *future* community members (a.k.a. prospective "new entrants"). On a good day it's just possible, with significant time and attention, to come up with stewardship policy solutions that satisfy that balancing requirement in both dimensions... or at least it is when the stakeholder community(s) are defined in explicitly technical terms. Throw "bean counter" interests into that mix, however, and that balancing exercise becomes impossible. >>>> >>>> If you have any doubts about this, I suggest that you try to imagine how you might feel if ASN privatization had taken place back in 1993-1994, before your network existed (or transitioned to BGP4/IDR). Now imagine that your best option for obtaining an ASN was your least favorite upstream provider. For extra points, you could also try imagining that you live somewhere where the total number of reachable upstream providers is between 0-2. >>>> >>>> If you can imagine yourself and/or your own "bean counters" being indifferent between that scenario -- or any other other that you can come up with -- and the current scenario in which you are able to obtain an ASN on neutral, technically defined, non-adversarial terms, then I encourage you to share it with the list; I will maintain an open mind. >>>> >>>> Thanks, >>>> >>>> TV >>>> >>>> P.S. IMO, that overlooked, forward-looking aspect of the stakeholder mandate is also one of the most important distinguishing features that separates what routing and addressing industry members do in this domain, individually and collectively, from the sort of activities that tend to attract very unfriendly (read: "unprofitable") attention from DOJ and other competition authorities. It's also the one thing that distinguishes what policy community members have chosen to do with respect to the disposition of IPv4 from what former Soviet politburo members chose to do with respect to the disposition of Russia's "public" assets back in 1991-1992. Please think *very* carefully abandoning that part of our mandate. >>>> >>>> >>>> _______________________________________________ >>>> 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. >>> >>> Tom, >>> >>> I am not tracking on your example pertaining to ASN privatization. I'm >>> in support of organizations being able to transfer their ASN >>> resources, not in support of entities being required to petition >>> telecom oligopolies to obtain resources. I am strictly in support of >>> proposals that give our constituents more freedoms, not less. >>> >>> IT/IS, management, and accounting are closely related, often >>> intersecting disciplines. I strongly believe that the opinions stated >>> by those opposed in this discussion thread are those of the former, >>> not of the latter. All 3 (and probably some others) are ARIN >>> stakeholders that must be represented. This is not to say that the >>> needs of management and accountants must completely supersede those of >>> IT/IS, but rather that those needs can be addressed in a manner that >>> does not unduly burden others. >> >> Hi Jeffrey, >> >> For the record, my own policy views are based on personal experience that straddles all three of the disciplines you cite, and is probably influenced more by my past "bean counting" work than anything else -- so you can nix that theory. I'm not worried about things that might happen, but rather about things that *will* happen, because they always happen when very clever people with specialized expertise encounter obscure but potentially lucrative strategic (technical/regulatory) arbitrage opportunities. What invariably happens is they "go for it" -- always -- even in cases where the loophole exploiters themselves are fully aware that what they're trying to do could (and likely will) have very far-reaching adverse consequences. They ignore such risks because doing so will pay off for their employers, at least in the short-term; because it'll be good for their own careers, reputations, and personal fortunes; because the competitive marketplace assures that if they don't go for >> it first, someone else will, eventually; and ultimately because it's great fun to be (or at least play at) master of the universe. Call that the "anti-stewardship" orientation. For better or worse, that's the role that many of us play (or have played at some point) in our professional lives, outside of this forum. And that's precisely why, IMO, we would all do well to be a little less coy about the realities of the marketplace in this forum. Because in the end, the best way to minimize any future temptation that you or I might face to go "rogue trader," and also to minimize the risk/harm that we and everyone else *will* face if enough of y/our competitors should succumb to such temptations, is to make sure that the exploitable loopholes that give rise to such temptations are closed, or at least made less attractive and kept under constant, close scrutiny. >> >> As for the claim that an ASN transfer policy would provide more freedom for stakeholders, that again completely ignores the temporal dimension that distinguishes "stewardship" from blind faith in markets. Your liberty to become a commercial ASN broker today would be purchased at the expense of future ASN seekers, who will be deprived of the opportunity that you and every other "incumbent" number resource stakeholder has enjoyed to date -- namely, the opportunity to obtain number resources on non-adversarial, technical needs-based terms from a non-competitor. >> >> I apologize if my previous examples were unclear, but let me try one more time, using the above argument. Say you currently work in the kind of environment where "good ideas" for cutting costs and/or increasing revenues are recognized and rewarded -- and where the most highly prized ideas of all are those that can be expected to pay off for a long long time, e.g., because they are opaque to competitors and third parties in general. The actual job you do might be in an IT/IS/engineering department, or in "business development," or in executive management. It really doesn't matter which: you're a "bean counter" of some kind, regardless of your actual title. From that perspective, please choose which of the three business conditions you would prefer: >> >> 1. I possess surplus reserves of a critical resource that my current competitors must obtain in order to grow, and without which prospective future competitors cannot even enter my market. They don't necessarily have to get the critical resource from me, but if they don't their only alternative is to get it from another market actor that has appx. the same strategic/competitive interests that I have with respect to this particular market. >> >> 2. I do not have enough of the critical resource to realize my Internet operations-business potential, and my only options are to try to obtain the resource from a current competitor, or from some other entity that knows that selling that resource to me will effectively make me a potential future competitor. Unless/until I obtain (more of) that critical resource, I cannot enter the Internet operations business/market and/or grow my business to its full potential. >> >> 3. I do not have enough of the critical resource, but if I can credibly demonstrate that my ability to enter the market and/or grow is contingent (only) on possession of that critical resource, then I can always obtain what I "need" on neutral, transparent, non-preferential terms from a non-competitor. >> >> You are free to choose (1), but only if you can find, say, 10 other current stakeholders that are willing to opt out of (2) in favor of (3). And even if you can manage that, you'll still need to come up with an argument that would persuasive enough to convince future stakeholders that their fortunes would be improved by being your (or someone else's) customer for ASNs, as opposed to being no ones customer for ASNs. >> >> I know it can be tempting to imagine that this would be a perfectly reasonable arrangement, which is why I encourage you to go through the whole hypothetical scenario once more, but this time imagining yourself in the same bean counter role, albeit a decade after all commercially viable ASNs have been privatized. This time you get no choice; you're stuck with (3). >> >> If you are truly indifferent between those two alternatives -- i.e., your bean counting aspirations would be equally fulfilled by status (1) or status (3), then you are to be commended for your genuine, consistent commitment to free market principles. I'm sure that ARIN will happily accept the return of your current ASNs, but no doubt the ASN transfer market will provide for whatever is needed thereafter. >> >> In fact, if everyone in favor of 2012-3 is willing to do the same, and abandon all claim to 100% of the ASNs currently in their possession, I just might be persuaded to support this policy. >> >> Any takers? >> >> TV >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. From bill at herrin.us Fri May 4 17:48:33 2012 From: bill at herrin.us (William Herrin) Date: Fri, 4 May 2012 17:48:33 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> Message-ID: On 5/4/12, John Curran wrote: > On May 4, 2012, at 2:33 PM, William Herrin wrote: >> What I assert is that much of the community would like ARIN to verify >> utilization using best available approaches at its discretion >> -excluding- those which would have ARIN consume PII about downstream >> ISP customers holding fewer than 8 IP addresses. > > If that's the case, you should then propose policy which precludes > ARIN from requesting that information. It's simple, clear, and can > be discussed by the community in a straightforward manner. John, As you wish. > Instead, you have proposed a process change that ARIN can request > this information, but only as last resort. Given that requesting > this information is the typical method for verifying utilization > of networks consisting of customer reassignments, I've asked you > several times what alternatives you propose for verifying the > utilization of these networks. At least three such methods have been proposed. One of them - a statistical analysis on the data - by you. > Those coming in for address space do not seem to have a problem > providing customer reassignment information This discussion started when several folks (none of them me) complained about providing /32 reassignment information on NANOG. As you well recall. > You should propose policy which precludes ARIN from requesting such > information if that is what you desire. We would then take customer > redelegations as valid as presented, and that should address your > concern. Automatically treating redelegations valid as presented in no way addresses my concern. In my opinion, any claim that is suspect or easily faked should be interrogated with the vigor you currently apply. It's one particular method you've begun to use which I think steps beyond the bounds of healthy behavior. > The only other option that has been clearly defined would be for ARIN > not ask for individual reassignments to customers but instead to consider > proof of infrastructure to be sufficient validation for an assertion of > IP utilization typical for such equipment. This is appears to be a > workable policy change to address your concern. I would think that any indirect evidence of a customer's existence would support the address utilization claim. A bank statement listing deposits and charges. A demonstration of access to the routers implied by assignment claims with apparent programming and interface statuses that match. A 10q or 10k filing listing customer counts. Really, I could go on for paragraphs about what sort of anonymous, indirect data could reasonably imply downstreams' existences in the claimed quantities. And so can you. 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 Fri May 4 18:12:17 2012 From: jcurran at arin.net (John Curran) Date: Fri, 4 May 2012 22:12:17 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> Message-ID: On May 4, 2012, at 5:48 PM, William Herrin wrote: > > I would think that any indirect evidence of a customer's existence > would support the address utilization claim. A bank statement listing > deposits and charges. A demonstration of access to the routers implied > by assignment claims with apparent programming and interface statuses > that match. A 10q or 10k filing listing customer counts. Really, I > could go on for paragraphs about what sort of anonymous, indirect data > could reasonably imply downstreams' existences in the claimed > quantities. Bill - Most excellent. That means another option is to write up one or more of these items that should be acceptable as evidence of utilization and submit as a suggestion into the ARIN Consultation and Suggestion process. . As it is, I don't know any alternative documentation that would definitely serve as verification of utilization as required by policy, but if the community supports one or more of the methods you supply, we're happy to proceed accordingly and can provide them as alternatives for verifying need to those requesting resources. Thanks! /John John Curran President and CEO ARIN From david at airbits.com Fri May 4 20:50:04 2012 From: david at airbits.com (David Krumme) Date: Fri, 4 May 2012 18:50:04 -0600 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> Message-ID: > I would think that any indirect evidence of a customer's existence > would support the address utilization claim. A bank statement listing > deposits and charges. Our bank statement shows all sources of our income and would not in any way tend to either validate or discredit our ISP activities. > A demonstration of access to the routers implied > by assignment claims with apparent programming and interface statuses > that match. I am not going to allow access to our routers to anyone out there on the Internet, out of security as well as trade secret concerns. Sorry. > A 10q or 10k filing listing customer counts. We don't file such reports. The 477 that American ISPs are required file at the FCC could be used, but I suppose it might be easy to lie to the FCC if one were so inclined. >Really, I > could go on for paragraphs about what sort of anonymous, indirect data > could reasonably imply downstreams' existences in the claimed > quantities. Maybe you could list at least one that would apply to a small ISP such as myself? I actually welcomed the request to provide the names of our subscribers. I could have sent phone numbers and even some photographs. :-) The subscribers were the one and only one reason we needed the IP addresses in the first place. Each IP address allows one flesh-and-blood individual to access the Internet to meet his or her needs. I feel like I am advocating on behalf of my customers in this regard, and I don't mind listing their names and IP addresses in order to advance their interests. I have only one customer who would have objected to having his IP address known by anyone. (I should have deleted his entry when I sent the list to ARIN...) He's a gun-lover who some folks might describe as being rather on the paranoid side. I try to humor him. -David From jcurran at arin.net Fri May 4 21:05:10 2012 From: jcurran at arin.net (John Curran) Date: Sat, 5 May 2012 01:05:10 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> Message-ID: <68FEADF0-4EF8-42EC-B540-6C4D845B0499@corp.arin.net> On May 4, 2012, at 8:50 PM, David Krumme wrote: > > I actually welcomed the request to provide the names of our subscribers. I > could have sent phone numbers and even some photographs. :-) The > subscribers were the one and only one reason we needed the IP addresses in > the first place. Each IP address allows one flesh-and-blood individual to > access the Internet to meet his or her needs. I feel like I am advocating > on behalf of my customers in this regard, and I don't mind listing their > names and IP addresses in order to advance their interests. David - Good to know; thanks for taking the time to comment on this. > I have only one customer who would have objected to having his IP address > known by anyone. (I should have deleted his entry when I sent the list to > ARIN...) He's a gun-lover who some folks might describe as being rather > on the paranoid side. I try to humor him. This reminds me - we're now actively working to determine appropriate retention for this more detailed information; we obviously need to have it long enough to review for determine utilization of the address blocks, and potentially some additional time to facilitate follow-on questions or appeals, but do not want to have this information being retained by ARIN any longer than needed. We'll provide an update to the community as soon as we have a revised process active which provides for minimal retention. Thanks & FYI, /John John Curran President and CEO ARIN From bill at herrin.us Fri May 4 22:05:43 2012 From: bill at herrin.us (William Herrin) Date: Fri, 4 May 2012 22:05:43 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> Message-ID: On 5/4/12, David Krumme wrote: >> I would think that any indirect evidence of a customer's existence >> would support the address utilization claim. A bank statement listing >> deposits and charges. > > Our bank statement shows all sources of our income and would not in any > way tend to either validate or discredit our ISP activities. Hi David, It would demonstrate a plausible customer count (or the lack thereof) for the address utilization you claimed. >> A demonstration of access to the routers implied >> by assignment claims with apparent programming and interface statuses >> that match. > > I am not going to allow access to our routers to anyone out there on the > Internet, out of security as well as trade secret concerns. Sorry. I believe the suggestion was for a webex session in which an ARIN rep on the phone asks you to operate the router and then observes (read-only) the result. Though I have to say I'm a little mystified by these trade secret concerns. Most businesses I know consider their customer list one of their most valuable trade secrets. And on the flip side, if you ask then ARIN staff is under NDA when they're viewing. >> A 10q or 10k filing listing customer counts. > > We don't file such reports. The 477 that American ISPs are required file > at the FCC could be used, but I suppose it might be easy to lie to the FCC > if one were so inclined. Sure, but that gets you in to civil or criminal penalties that you don't face lying to ARIN. Same with asking to see your tax returns as a spot check on whether your revenues tend to support or refute the claimed level of utilization. Many virtual server providers ask to see a scan of your driver's license before they'll open an account. Blacked out sections, low resolution, all fine. Do you know why? Because faking a government photo ID is at least a class 1 misdemeanor and they figure most scammers won't commit an actual crime as a gateway into mere civil fraud. >> Really, I >> could go on for paragraphs about what sort of anonymous, indirect data >> could reasonably imply downstreams' existences in the claimed >> quantities. > > Maybe you could list at least one that would apply to a small ISP such as > myself? I'll list two: Employee count to see if you're over the low water mark typical for the size of your address holdings. A de-identified data dump from your configuration system that shows what (e.g. dialup accounts, email boxes, etc.) but not who (no account names, real names, addresses, etc). But do you see what you've done here? You've ruled out several perfectly reasonable ways to infer the reasonable range of legitimate utilization simply because you don't like them. Why shouldn't the other guy get the same opportunity to rule out the PII one that makes him nervous in favor of the bank statements or router configs? And oh by the way, I'm not sure you realized it when you posted this but if ARIN feels the need they'll ask for the customer list associated with one or more of your dynamic pools as well, not just restrict themselves to the statics as they've done so far. So says John Curran. > I actually welcomed the request to provide the names of our subscribers. I Fantastic. And I would be well satisfied if you chose that method of validating your utilization over the others. Convince John Curran that there's a way to do that without taking away anybody else's choice to provide a tour of the routers instead of the PII and I'll write it up. 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 Fri May 4 22:20:07 2012 From: jcurran at arin.net (John Curran) Date: Sat, 5 May 2012 02:20:07 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> Message-ID: On May 4, 2012, at 10:05 PM, William Herrin wrote: > > I'll list two: > > Employee count to see if you're over the low water mark typical for > the size of your address holdings. > > A de-identified data dump from your configuration system that shows > what (e.g. dialup accounts, email boxes, etc.) but not who (no account > names, real names, addresses, etc). Bill - If you believe that either of the two are sufficient, please write them up. We have not been asking employee count so it is unclear what heuristic is to be used for "assumed utilization based on # of service provider employees" and some guidance will be needed there. Same with respect to acceptable ratios of dialup accounts and/or email boxes to IP address utilization. > ... > Fantastic. And I would be well satisfied if you chose that method of > validating your utilization over the others. Convince John Curran that > there's a way to do that without taking away anybody else's choice to > provide a tour of the routers instead of the PII and I'll write it up. It is not David's job to write it up; he's not the one seeking an alternative. You are seeking to establish some alternatives and therefore you carry the burden of documenting your suggestions so that folks in the community can read them and consider if they are fair and technically sound. Thanks! /John John Curran President and CEO ARIN From david at airbits.com Fri May 4 23:12:30 2012 From: david at airbits.com (David Krumme) Date: Fri, 4 May 2012 21:12:30 -0600 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> Message-ID: <2d4508ed4c158d83026ea52210a0d465.squirrel@webmail.airbits.com> > On 5/4/12, David Krumme wrote: >>> I would think that any indirect evidence of a customer's existence >>> would support the address utilization claim. A bank statement listing >>> deposits and charges. >> >> Our bank statement shows all sources of our income and would not in any >> way tend to either validate or discredit our ISP activities. > > Hi David, > > It would demonstrate a plausible customer count (or the lack thereof) > for the address utilization you claimed. Um...our income comes from lots of sources and nothing on the bank statement would indicate the source of the income. I guess our total revenue would show up as being sufficient, but how much of that was due to Internet service would be impossible to detect. I don't see that that would be very informative. > >>> A demonstration of access to the routers implied >>> by assignment claims with apparent programming and interface statuses >>> that match. >> >> I am not going to allow access to our routers to anyone out there on the >> Internet, out of security as well as trade secret concerns. Sorry. > > I believe the suggestion was for a webex session in which an ARIN rep > on the phone asks you to operate the router and then observes > (read-only) the result. The routers, for example, contain WEP and WPA keys disclosed in plaintext to the person logged in to the router, and to anyone who might also be observing. Maybe I'm being too paranoid, but I've always guarded any and all access to our servers and routers instinctively. > Though I have to say I'm a little mystified by these trade secret > concerns. Most businesses I know consider their customer list one of > their most valuable trade secrets. And on the flip side, if you ask > then ARIN staff is under NDA when they're viewing. Everyone in town knows who our customers are. It's the opposite of a secret. Most of our customers have our name built into their email addresses. In this regard, an ISP is rather different from most businesses. Of course, I wouldn't disseminate a complete list of customers, but I take it for granted that ARIN will keep the complete list confidential. > >>> A 10q or 10k filing listing customer counts. >> >> We don't file such reports. The 477 that American ISPs are required file >> at the FCC could be used, but I suppose it might be easy to lie to the >> FCC >> if one were so inclined. > > Sure, but that gets you in to civil or criminal penalties that you > don't face lying to ARIN. Same with asking to see your tax returns as > a spot check on whether your revenues tend to support or refute the > claimed level of utilization. So the 477 might be a good kind of justification. But I don't know whether as a practical matter one could convince the FCC to divulge it to ARIN, even if I gave them permission to do so. If this could be done, though, it might be a really good form of substantiation, and it could have the side-effect of encouraging ISPs to be honest with the FCC. > Many virtual server providers ask to see a scan of your driver's > license before they'll open an account. Blacked out sections, low > resolution, all fine. Do you know why? Because faking a government > photo ID is at least a class 1 misdemeanor and they figure most > scammers won't commit an actual crime as a gateway into mere civil > fraud. > > >>> Really, I >>> could go on for paragraphs about what sort of anonymous, indirect data >>> could reasonably imply downstreams' existences in the claimed >>> quantities. >> >> Maybe you could list at least one that would apply to a small ISP such >> as >> myself? > > I'll list two: > > Employee count to see if you're over the low water mark typical for > the size of your address holdings. We are a family business with no actual employees but several people working part-time, so that might be hard to evaluate. Also, our people are very productive, so we would probably look too small. I would be disappointed to think that our staff-to-customer ratio was anything close to what is typical for the industry. > A de-identified data dump from your configuration system that shows > what (e.g. dialup accounts, email boxes, etc.) but not who (no account > names, real names, addresses, etc). Something based on email accounts could indeed be very informative. But without disclosing actual email addresses, it's not clear what useful information could be disclosed. > > But do you see what you've done here? You've ruled out several > perfectly reasonable ways to infer the reasonable range of legitimate > utilization simply because you don't like them. Why shouldn't the > other guy get the same opportunity to rule out the PII one that makes > him nervous in favor of the bank statements or router configs? I only ruled them out because it seemed that they would be uninformative. > And oh by the way, I'm not sure you realized it when you posted this > but if ARIN feels the need they'll ask for the customer list > associated with one or more of your dynamic pools as well, not just > restrict themselves to the statics as they've done so far. So says > John Curran. > I think they should. I see little difference between static and dynamic for customers with permanent connections because "dynamic" ones are online all the time anyway and there is going to be close to a 1:1 correspondence between customers and IP addresses in use. -David From bill at herrin.us Sat May 5 00:22:51 2012 From: bill at herrin.us (William Herrin) Date: Sat, 5 May 2012 00:22:51 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <2d4508ed4c158d83026ea52210a0d465.squirrel@webmail.airbits.com> References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> <2d4508ed4c158d83026ea52210a0d465.squirrel@webmail.airbits.com> Message-ID: On 5/4/12, David Krumme wrote: >> On 5/4/12, David Krumme wrote: >>>> I would think that any indirect evidence of a customer's existence >>>> would support the address utilization claim. A bank statement listing >>>> deposits and charges. >>> >>> Our bank statement shows all sources of our income and would not in any >>> way tend to either validate or discredit our ISP activities. >> >> Hi David, >> >> It would demonstrate a plausible customer count (or the lack thereof) >> for the address utilization you claimed. > > Um...our income comes from lots of sources and nothing on the bank > statement would indicate the source of the income. I guess our total > revenue would show up as being sufficient, but how much of that was due to > Internet service would be impossible to detect. I don't see that that > would be very informative. Hi David, It's not so much the dollars as the transaction count. If you claim 90% of a /18 is /32's and dynamic pools but your statement shows 50 transactions a month, something is very off. The transaction count won't prove that your utilization report is legit any more than a list of names and addresses does and it isn't intended to. It's simply an attempt to catch you in a lie. If you don't get caught in a lie then the presumption is that you're telling the truth. >> Employee count to see if you're over the low water mark typical for >> the size of your address holdings. > > We are a family business with no actual employees but several people > working part-time, so that might be hard to evaluate. Also, our people are > very productive, so we would probably look too small. I would be > disappointed to think that our staff-to-customer ratio was anything close > to what is typical for the industry. If you're adding a /18 to your /20, half of it /32s and dynamic pools yet have no full time employees then something is fishy. Unless you've subbed out the tech work (which you can easily prove) there aren't enough hours in the day for a couple people working part time to keep up with an efficiently numbered network of that scale. It's a question of consistency. Any way I ask the question, the story of your business should be a story of one that could legitimately use the addresses in the way you claimed. I can ask the question many ways; I don't have to ask it in terms of customer identities to get a coherent answer. >> A de-identified data dump from your configuration system that shows >> what (e.g. dialup accounts, email boxes, etc.) but not who (no account >> names, real names, addresses, etc). > > Something based on email accounts could indeed be very informative. But > without disclosing actual email addresses, it's not clear what useful > information could be disclosed. Customer count. I can infer your rough customer count from the list of configured services. And its more likely to be truthful than just asking you the sum. If you fake it and then I ask for the list of transactions on your bank statement and the two don't make any sense together than I've caught you in a lie. Meanwhile, if you have a /22 deployed to DHCP pools and another /24 to /32 statics but your customer count is 500 then something is fishy. Either they're not really deployed that way or you're not at 80% utilization. If the customer count I inferred from the indirect data is around 1500 the those same deployments then I can have a reasonably high confidence that you've told the truth. Sure, you could have lied to me... most customers buy something else from you and only 50 of them buy IP services. But if you're this good at telling a consistent lie then reading a list of names and addresses isn't going to bust you either. In fact, unless I'm prepared to pick up the phone and start polling the folks on that customer list, I have just as much confidence that you're telling the truth this way as I do from demanding a customer list. ARIN polling a random selection of the customer list. Doesn't that open a can of worms. 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 Sat May 5 01:09:47 2012 From: jcurran at arin.net (John Curran) Date: Sat, 5 May 2012 05:09:47 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> <2d4508ed4c158d83026ea52210a0d465.squirrel@webmail.airbits.com> Message-ID: On May 5, 2012, at 12:22 AM, William Herrin wrote: > > Sure, you could have lied to me... most customers buy something else > from you and only 50 of them buy IP services. But if you're this good > at telling a consistent lie then reading a list of names and addresses > isn't going to bust you either. > > In fact, unless I'm prepared to pick up the phone and start polling > the folks on that customer list, I have just as much confidence that > you're telling the truth this way as I do from demanding a customer > list. With all due respect Bill, it is not quite as easy to produce a set of customer reassignment data as you would think, and there are ways of spot checking individual entries short of directly contacting them. You should be able to infer some of them; I'd rather not directly outline how to fabricate the appropriate external supporting data. You may be able to add reassignments which aren't caught in spot checking, but you'd find it difficult to create quantities of believable customers sufficient to move your utilization in a major way. FYI, /John John Curran President and CEO ARIN From bill at herrin.us Sat May 5 08:47:45 2012 From: bill at herrin.us (William Herrin) Date: Sat, 5 May 2012 08:47:45 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> <2d4508ed4c158d83026ea52210a0d465.squirrel@webmail.airbits.com> Message-ID: On 5/5/12, John Curran wrote: > On May 5, 2012, at 12:22 AM, William Herrin wrote: >> In fact, unless I'm prepared to pick up the phone and start polling >> the folks on that customer list, I have just as much confidence that >> you're telling the truth this way as I do from demanding a customer >> list. > > With all due respect Bill, it is not quite as easy to produce a > set of customer reassignment data as you would think, and there > are ways of spot checking individual entries short of directly > contacting them. Hi John, I never claimed it was easy but I doubt it's particularly harder than I think. The keys are: expectations, consistency and error. The expectations are for a healthy mix of assignments: dynamic pools and static assignments of various sizes with the larger static assignments properly swipped. Staking a claim of 90% /32's is foolish unless true. Might even be foolish if true because it invites scrutiny. Submit a claim that "looks" right and you'll get only a few cursory questions. Consistency is the hard part of any lie. I won't belabor it or the methods for achieving it. Error is important. A surprisingly large amount of information in an ISP's billing database is missing or wrong and obviously so. The smaller the ISP, the more true. A faker really has to have seen enough such databases to understand the kinds of error that are present and introduce similar error into his faked data. Too-perfect data is a red flag. Back when I was in the business we acquired a bunch of smaller ISPs with a few hundred to a thousand customers each. One of them was missing complete address data for half the customers. He had most of them on annual plans (with a believable mix of end dates) and said a number of them dropped by his shop and paid in person. Ended up in court because the contract called for us to pay him for essentially the opportunity to bring these customers into our system yet for many he didn't provide enough information to reach out and contact them. Meanwhile we carried these customers and continued service for them because even if we couldn't get in touch with them there was a decent chance they'd get in touch with us when the annual contract came due. No more expensive really than acquiring a customer through advertising. Point is, you expect goofy crap like that to be reflected in the customer data. If it isn't there then it may be faked. In my opinion, though, you can get the same feel from the de-identified data. It's a little more effort, but only a little. Heck, you can infer from just the list of plan durations and end dates. If there are annual subscriptions but no cluster around Christmas and no late-summer dip then something is odd. And you don't need the slightest bit of PII to check. 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 Sat May 5 09:54:59 2012 From: jcurran at arin.net (John Curran) Date: Sat, 5 May 2012 13:54:59 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> <2d4508ed4c158d83026ea52210a0d465.squirrel@webmail.airbits.com> Message-ID: <77D351F1-C8DA-4999-89D7-7ABC7E432790@arin.net> On May 5, 2012, at 8:47 AM, William Herrin wrote: > Point is, you expect goofy crap like that to be reflected in the > customer data. If it isn't there then it may be faked. In my opinion, > though, you can get the same feel from the de-identified data. It's a > little more effort, but only a little. Yes, you have asserted that several times, and I believe I understand your position. > Heck, you can infer from just the list of plan durations and end > dates. If there are annual subscriptions but no cluster around > Christmas and no late-summer dip then something is odd. And you don't > need the slightest bit of PII to check. Verification (of address block utilization) via inference is certainly an innovative approach, and if your policy proposal version 2.0 is adopted, we will do our best to perform such for address blocks whose utilization level is significantly based on customers with smaller than /29 reassignments. Thanks! /John John Curran President and CEO ARIN From bill at herrin.us Sat May 5 12:25:46 2012 From: bill at herrin.us (William Herrin) Date: Sat, 5 May 2012 12:25:46 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <77D351F1-C8DA-4999-89D7-7ABC7E432790@arin.net> References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> <2d4508ed4c158d83026ea52210a0d465.squirrel@webmail.airbits.com> <77D351F1-C8DA-4999-89D7-7ABC7E432790@arin.net> Message-ID: On 5/5/12, John Curran wrote: > On May 5, 2012, at 8:47 AM, William Herrin wrote: >> Heck, you can infer from just the list of plan durations and end >> dates. If there are annual subscriptions but no cluster around >> Christmas and no late-summer dip then something is odd. And you don't >> need the slightest bit of PII to check. > > Verification (of address block utilization) via inference is certainly an > innovative approach, and if your policy proposal version 2.0 is adopted, > we will do our best to perform such for address blocks whose utilization > level is significantly based on customers with smaller than /29 > reassignments. Hi John, I would argue that ARIN already verifies by inference. It may be semantics, but without direct evidence of contact (copy of photo ID, copy of a check, credit card numbers, SSN, phone check) a list of names is just a list of names. ARIN infers actual use from the list. I merely propose you exclude PII from the data set from which you draw inference. Really, I don't even want that much. I want you to exclude PII *until* the applicant balks at a request for non-PII data. An otherwise cooperative applicant, like Jack, should never need to turn over sub-/29 PII to complete the process. Folks like David, who is sensitive about different information instead, ought to be able to complete the process using the PII. One standard. Multiple options. Applicant empowered to select. Give me a way to write such an eminently sensible policy which isn't capriciously excluded from the policy process. I really don't appreciate being forced into a mold that makes the proposal less reasonable. Regards. Bill -- 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 Sat May 5 12:30:35 2012 From: jcurran at arin.net (John Curran) Date: Sat, 5 May 2012 16:30:35 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> <2d4508ed4c158d83026ea52210a0d465.squirrel@webmail.airbits.com> <77D351F1-C8DA-4999-89D7-7ABC7E432790@arin.net>, Message-ID: <2EE2AA2A-62BE-479A-9DF2-F045D3AD69F5@arin.net> On May 5, 2012, at 12:25 PM, "William Herrin" wrote: > Give me a way to write such an eminently sensible policy which isn't > capriciously excluded from the policy process. I really don't > appreciate being forced into a mold that makes the proposal less > reasonable. Simply specify what data you'd like ARIN to request in lieu of customer assignment data, and how to tie that back to address block utilization. Thanks! /John John Curran President and CEO ARIN From david at airbits.com Sat May 5 12:42:46 2012 From: david at airbits.com (David Krumme) Date: Sat, 5 May 2012 10:42:46 -0600 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> <2d4508ed4c158d83026ea52210a0d465.squirrel@webmail.airbits.com> Message-ID: Bill, I like your ideas which are quite clever. However, my situation doesn't match your expectations. Maybe I am unique...? > The expectations are for a healthy mix of assignments: dynamic pools > and static assignments of various sizes with the larger static > assignments properly swipped. All my customers are assigned individual /32's. I don't know why I would be using dynamic pools for customers who are permanently connected and who tend to use the Internet every day. I've never had anyone want a /29. > Error is important. A surprisingly large amount of information in an > ISP's billing database is missing or wrong and obviously so. The > smaller the ISP, the more true....Too-perfect data is a red flag. Our billing database is almost perfectly error-free. We audit it once a month because it's less work to keep it straight than to deal with the fallout from billing errors. We are about as small as they come. In my experience, it is the really big providers that are so error-prone. > Heck, you can infer from just the list of plan durations and end > dates. If there are annual subscriptions but no cluster around > Christmas and no late-summer dip then something is odd. And you don't > need the slightest bit of PII to check. We don't have any plan durations or end dates or annual subscriptions. So I'm just saying that your techniques are based on certain assumptions about how an ISP is run, assumptions that do not characterize my situation. -David From bill at herrin.us Sat May 5 13:06:08 2012 From: bill at herrin.us (William Herrin) Date: Sat, 5 May 2012 13:06:08 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <2EE2AA2A-62BE-479A-9DF2-F045D3AD69F5@arin.net> References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> <2d4508ed4c158d83026ea52210a0d465.squirrel@webmail.airbits.com> <77D351F1-C8DA-4999-89D7-7ABC7E432790@arin.net> <2EE2AA2A-62BE-479A-9DF2-F045D3AD69F5@arin.net> Message-ID: On 5/5/12, John Curran wrote: > On May 5, 2012, at 12:25 PM, "William Herrin" wrote: >> Give me a way to write such an eminently sensible policy which isn't >> capriciously excluded from the policy process. I really don't >> appreciate being forced into a mold that makes the proposal less >> reasonable. > > Simply specify what data you'd like ARIN to request in lieu of customer > assignment data, and how to tie that back to address block utilization. Show me where current policy specifies what data ARIN requests to verify claims of dynamic pools and sub /29 assignments and how that ties to utilization. I'll model my language on it. 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 May 5 13:42:41 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 5 May 2012 12:42:41 -0500 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> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <8EB5E74F-9E9C-45BB-8608-8052E45610A4@netconsonance.com> Message-ID: On 5/3/12, William Herrin wrote: > Due respect Jimmy, read up on DNS pinning. The whole point is to hold > the first IP address beyond the the TTL. It's the solution to a > particularly nasty javascript vulnerability. DNS pinning comes into play, only for low-TTL records. Keep the TTL for your DNS records 86400 or higher, and there is no pinning. DNS Pinning is an "excuse", not a legitimate reason not to renumber. The specified security function of DNS pinning for low TTL records is to a specific prevent rebinding attack which is a time-sensitive attack -- DNS pinning anything without a low TTL was not part of the spec and would be uncalled for. Noone here has actually identified any commonly used browser that has DNS pinning which is broken in the manner suggested. There is no documented proof available that specific implementations of DNS pinning are broken, or that it is a real issue even over a transition staged over a substantial length of time. Again, browser windows don't get left open for 2 months, let alone 6 or 12. It is pretty much unheard of, unless, that browser is solely being pointed to your one site and doing nothing else, over the entire timeframe, with the page constantly being loaded, for the purpose of intentionally having an issue. Web browsers aren't that stable, require constant updates due to bugs in plugins such as Flash/Acrobat, and don't see those kinds of uptimes, even if the browser has a broken implementation that does DNS PIN until restart. Heck... Desktop OSes are not that stable, and it is critical that they be updated frequently; uptimes above 30 days are rare, 6 month uptimes are almost unheard of, And the policy provides 12 months. It's certainly feasible to transition DNS records for 255 hosts within 90 days, have your IT staff provide a period of dual-IP of sufficient length so that requests to the old address become vanishingly small. Require your IT staff to monitor requests that do come in at the old IP address, after a period of time, and identify any issues, repeat until all issues are gone. And i'm sure ARIN can offer some sort of extension to the 12 months with good cause (?) There is no pain whatsoever involved, given enough time, and 12 months is a lot of time. Renumbering is a simple incremental procedure. -- -JH From bill at herrin.us Sat May 5 14:21:16 2012 From: bill at herrin.us (William Herrin) Date: Sat, 5 May 2012 14:21:16 -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> <7E7773B523E82C478734E793E58F69E76951DADA@SBS2011.thewireinc.local> <895B8A31-1BD8-489F-A2DB-A8B258F04A90@netconsonance.com> <8EB5E74F-9E9C-45BB-8608-8052E45610A4@netconsonance.com> Message-ID: On 5/5/12, Jimmy Hess wrote: > On 5/3/12, William Herrin wrote: >> Due respect Jimmy, read up on DNS pinning. The whole point is to hold >> the first IP address beyond the the TTL. It's the solution to a >> particularly nasty javascript vulnerability. > > DNS pinning comes into play, only for low-TTL records. Keep the TTL > for your DNS records 86400 or higher, and there is no pinning. Hi Jimmy, That hasn't been my experience but your mileage may vary. > Again, browser windows don't get left open for 2 months, Sometimes mine do. Who are you to say otherwise? > Heck... Desktop OSes are not that stable, and it is critical that > they be updated frequently; uptimes above 30 days are rare, 6 > month uptimes are almost unheard of, For the record, one of my desktops has been up for 262 days. One of my *windows* desktops has been running for 35 days. Maybe I'm just better at keeping my equipment online. ;-) > And the policy provides 12 months. And all of this is *why* we picked 12 months instead of 3 or 6 back when the policy was written. So that there would be *plenty* of time for a successful renumbering, despite the very significant difficulties and pain. 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 Sat May 5 14:25:53 2012 From: bill at herrin.us (William Herrin) Date: Sat, 5 May 2012 14:25:53 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement Message-ID: On 5/5/12, David Krumme wrote: > I like your ideas which are quite clever. However, my situation doesn't > match your expectations. Maybe I am unique...? Hi David, Maybe unique. Or just moving through an early phase where certain kinds of expedience still make sense. >> The expectations are for a healthy mix of assignments: dynamic pools >> and static assignments of various sizes with the larger static >> assignments properly swipped. > > All my customers are assigned individual /32's. I don't know why I would > be using dynamic pools for customers who are permanently connected and who > tend to use the Internet every day. Doesn't scale up and its a nuisance to keep track of. When you have 10,000 /32's and redundant paths in your network, you'll find that some of your edge equipment has trouble dealing with the routes. Dynamic pools aggregate better and with the right software you can give the assignments some stickiness so the customer tends not to get a different address unless he moves to a different pool. Assignment and revocation via dynamic pools also automates easier than static /32's. >> Error is important. A surprisingly large amount of information in an >> ISP's billing database is missing or wrong and obviously so. The >> smaller the ISP, the more true....Too-perfect data is a red flag. > > Our billing database is almost perfectly error-free. We audit it once a > month because it's less work to keep it straight than to deal with the > fallout from billing errors. I'll bet you anything you want it's not as perfect as you think. Somewhere in there Bob's niece Clara has free service as a courtesy to the very valuable Bob. It wasn't deleted when Bob left you for Verizon. Also, your typos and goofs will have a different character than the ones I'd get from a bulk mailing list. Mr. Ben Dover and Ms. Richard Johnson are probably not to be found. Ralhp Jone likely is. >> Heck, you can infer from just the list of plan durations and end >> dates. If there are annual subscriptions but no cluster around >> Christmas and no late-summer dip then something is odd. And you don't >> need the slightest bit of PII to check. > > We don't have any plan durations or end dates or annual subscriptions. At some point you send out a bill or auto-debit a credit card. That's the end date. Then service begins again. > So I'm just saying that your techniques are based on certain assumptions > about how an ISP is run, assumptions that do not characterize my > situation. One size doesn't fit all. The PII method works for you. I heard you loud and clear the first time. I just can't do anything about it unless John finds a way around his pronouncement that anything between the extremes of using PII whenever and not using PII at all is out of bounds at the policy level. He has us boxed in. I hope you'll forgive me but if I'm forced to choose between you playing show and tell with the routers and a hospital either reorganizing its network or coughing up patient ids, I'll choose to inconvenience you. 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 Sat May 5 15:36:01 2012 From: jcurran at arin.net (John Curran) Date: Sat, 5 May 2012 19:36:01 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> <2d4508ed4c158d83026ea52210a0d465.squirrel@webmail.airbits.com> <77D351F1-C8DA-4999-89D7-7ABC7E432790@arin.net> <2EE2AA2A-62BE-479A-9DF2-F045D3AD69F5@arin.net>, Message-ID: <85F4DB33-D35B-41C8-B2B1-03B9C883FFBB@arin.net> On May 5, 2012, at 12:06 PM, "William Herrin" wrote: >> Simply specify what data you'd like ARIN to request in lieu of customer >> assignment data, and how to tie that back to address block utilization. > > Show me where current policy specifies what data ARIN requests to > verify claims of dynamic pools and sub /29 assignments and how that > ties to utilization. I'll model my language on it. Bill - ARIN asks for whatever information is necessary to verify the assignments that have been made from an address block, as that information is required for verification of the address block utilization. Per policy, additional allocations can not be made until existing address block utilization is verified. There is no existing language which specifies only certain information is to be requested in verifying utilization; you are in uncharted territory. I believe your revised policy proposal will accomplish some of what you intended, as under that policy proposal ARIN would request only redacted information for assignments which are smaller than /29. However, if you have any questions on how this or other policy language will be implemented, and for sake of expediency over email discourse, please feel free to call me anytime (+1 617 512 8095) and I will address any questions you may have on proposed policy language. Thanks! /John John Curran President and CEO ARIN From joelja at bogus.com Sat May 5 00:37:38 2012 From: joelja at bogus.com (Joel jaeggli) Date: Fri, 04 May 2012 21:37:38 -0700 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <50075C07-6D84-4753-83E3-DFDE52A229E6@burkov.aha.ru> <4FA1DF23.1000807@redbarn.org> <4FA2DCBC.6020303@redbarn.org> <4FA2F0DC.80505@bogus.com> Message-ID: <4FA4AE92.2020405@bogus.com> On 5/3/12 14:19 , William Herrin wrote: > On 5/3/12, Joel jaeggli wrote: >> On 5/3/12 13:21 , William Herrin wrote: >>> On Thu, May 3, 2012 at 3:30 PM, paul vixie wrote: >>>> and i don't see anyone other than the RIRs who could do it. >>>> >>>> and i don't see any way to continue the internet's prior growth curve >>>> without this. >>> >>> As ISPs begin to make use of the carrier NAT space where a single >>> global IP serves hundreds of customers, is it really necessary for >>> ARIN to spot-check the identities of the customers sitting behind a >>> particular address in order to verify that the use is legitimate? >> >> ranges used by nat translators should be documented as such. they are >> not customer assignments. I've done this in the course of direct >> assignment requests. I have not yet been asked to demonstrate outgoing >> port utlization efficiency whatever that my imply at some future date. > > Hi Joel, > > Has anyone at ARIN promised you it won't do so in your next round? No-one from arin has promised me anything... > Unless I misunderstood John Curran, he said that and anything else > which consumes IP addresses is fair game. If you are using overload nat, but especially in the deterministic port range assignment context it's fairly straight forward to calculate your port consumpution on the basis of a rather small sample of the flows. > He said they don't ask > egregiously. But they also won't go out of their way to avoid asking. The run rate from a cluster in our environment on the logging for outgoing nat mappings when enabled is around 400,000 lines a second. A 1 minute snapshot of that is super interesting reading once sources and destinations are anonymized. > Regards, > Bill Herrin > > From drake.pallister at duraserver.com Mon May 7 00:27:17 2012 From: drake.pallister at duraserver.com (Drake Pallister) Date: Mon, 7 May 2012 00:27:17 -0400 Subject: [arin-ppml] ARIN-prop-168 Promote 4byte ASN Usage References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com><4FA02C10.7060408@arin.net><513304D5-E827-4F53-AD4A-2D0EB9E9777F@delong.com><4FA188EC.6030406@chl.com> <4FA2EA7C.5000709@chl.com> Message-ID: Hello Gentlemen, I hope I am welcomed to chime in on the subject in a general manner with some thoughts for whatever they're worth. Maybe I'm a day late and a dollar short, or even on the riding on the wrong bus as to your specific debate. Relative to an Org being able to choose a specific ASN if they are aware of its availability, may I toss in a couple of comparisons in both directions? I'll not comment on any technical aspects of backward compatibility, AS_Trans 23456, new & old interoperability with older equipment, etc. I would agree that an Org may have valid have reasons for desiring a specific AS number, whether it be for aesthetics, superstition, or to provide a unified structure with any other numeric configurations they might have; or recovering a lost 4byte AS number for whatever reason. Vanity ASN's like vanity license plates? Now that's a real seller. ASDOT looks nice-- ASPLAIN, just another bigger number.That may boil down to how your equipment wants it formatted. We didn't get to pick IP nets for allocations, but if ARIN desires to bolster the issuance of 32 bit ASN's then allowing specific choices might help. Sooner or later [sooner] the16 bit depletion aspect leaves no choice if an Org wants an ASN. When starting up new telephone account or adding an extra line, you're generally given the choice to pick from a group of available phone numbers in your area within reason. If your street address numeral is all that important, then you could choose to buy one house over another. The US Postal service along with the City actually renumbered the street I live on. It was done for unification and to eliminate duplicate and misaligned house numbers. I do not like the new number, but am stuck with a longer and undesirable house number. An overlay/transition period of a year, allowing either house number to be was employed to alert necessary persons that the address has changed. This can remotely be compared to network renumbering via IP or AS. With a US Postal street-renumbering there is a finite period before mail showing the old house number would be returned to sender. Any comparison to Internet routing? After the overlay period, NO backward compatibility existed, so to extend the finite cutover date for ourselves, we used both the new house number and the old one in parentheses. However this is not the case as with AS 2 & 4 byte but it makes for an analogy. If an Org's management desires certain combinations of numerals I would agree with a request for a specific 4byte AS number. Naturally a good practice would be to allow returned (yeah) unneeded numbers an adequate cool-off period before re-issuance as a second-hand ASN may come with skeletons in the closet. The quantity of 32 bit is so large that surrendered ones could cool off for a very long time. An exception would be in a recovering of a negligently or otherwise lost ASN. On the other hand, and generally speaking it makes sense administratively to start at the beginning and work their way upward while issuing. That would prevent the AS number inventory from being scattered all over the place. I would see an all out ASN-4 issuing-by-request as a potential administrative nightmare for ARIN, with large unfilled issuance gaps. A mitigating idea for that may be as follows: Summary: I suppose my suggestion would be to allow requested specific ASN's within ranges as ARIN might open up a new range and requests could be made from that range only; until a new range was made available for issuing via sequential selection or by request. To keep honoring requested ASN's, gaps would still remain in each range. If ARIN's desire is to not maintain big gaps, (hence an administrative nightmare), then perhaps an additional component might be employed such as a premium fee for a requested number and a discounted fee for a random assignment. In the end the premiums and discounted may even out dollar-wise. If ARIN's stewardship is developing a commercial twist, then a request for a specific ASN from a not-yet opened range could even be accommodated for yet an extra premium. Since IPv6 and 32bit ASN's have been phasing in around the same timeframe then it might even be considered to allow speific IP net allocations. Conclusion: It would not be a terrible thing to issue a requested ASN provided the Org has a decent reason, and such a practice doesn't impose an administrative nightmare on ARIN. Only Best Regards, Drake Pallister ----- Original Message ----- From: "Joe Maimon" To: "Owen DeLong" Cc: Sent: Thursday, May 03, 2012 4:28 PM Subject: Re: [arin-ppml] ARIN-prop-168 Promote 4byte ASN Usage > Owen, > > Thanks for the excellent feedback. I suppose at this time I can wait and > see if the AC wants to adopt the proposal and to work on it or if a > rewrite is in order. > > I'll give it some thought. > > Joe > > Owen DeLong wrote: >> On May 2, 2012, at 12:20 PM, Joe Maimon wrote: >> >>> Hey Owen, >>> >>> Owen DeLong wrote: >>>> I could support this policy with the following changes: >>>> >>>> 5.2.2 Remove "AS Number or" from the first sentence. >>> >>> To clarify, you are objecting to language that would allow an org to >>> request a specific AS from ARIN, assuming it knows it is available. >>> >>> Yes, this allows an org the chance to try and get an aesthetically or >>> otherwise pleasing ASN they may not have otherwise. >>> >>> Whats the harm in that? >>> >> I'm generally opposed to putting ARIN in the "custom license plate" >> business because I think there are other better higher priorities for >> number resource management. >> >>> But if dropping it is all it would take to win public support, its an >>> easy loss. >>> >> Don't know about that. Certainly dropping it is a requirement to garner >> my support. >> >>>> 5.2.3 I don't understand what causes are being rectified, so, this >>>> entire >>>> paragraph does not yet make sense to me. I would appreciate >>>> clarification >>>> from the author. >>> >>> In the simplest case, it would allow ARIN to explain to the room at some >>> future ppm why 4byte ASN utilization is so low, put the pages in the >>> wiki, document and present to the community other potentially valid >>> concerns, produce material that can be useful to parties involved in >>> similar situations, etc... >>> >>> Yes, this may allow ARIN to operate a 4byte wall of shame. >>> >> I have no problem with policy enabling ARIN to operate a 4-octet wall of >> shame. However, if that is the intent, let's have the paragraph say that. >> I can't even parse what it says currently. >> >> I don't think ARIN knows why 4-octet ASN utilization is so low (in the >> ARIN region and uniquely in the ARIN region, btw). >> >>>> 5.2.4 I would prefer to see a longer period. >>> Anything from 12-48 months is fine with me, personally. >>> >>> However, consider that this restriction as written applies to both 8.2 >>> and 8.3 transfers. >>> >> I would modify to remove the restriction from 8.2 transfers and set the >> limit at 48 months (if we're going to allow 8.3 transfers of ASNs at all >> which I still feel is a bad idea). >> >>>> 5.2.5 I don't really see a purpose to this clause. I would delete it. >>> >>> An organization that wants to transfer an ASN, but cannot because 5.2.4 >>> applies to it, has the option to exchange the ASN for a 5.2.1 which has >>> no such restriction, should they wish to avail themselves of it. >>> >>> I suppose some grace time for renumbering may not be a bad idea. >>> >> Ah, but if we eliminate 5.2.3 as I suggested, that becomes inoperative. >> >>>> 5.2.6 is a no-op. It should be removed. >>> >>> Its there to prevent ARIN staff from concluding that in order to >>> implement 5.2.2 they need to publish an entire list of available ASNs, >>> which they may reasonably do so without making it explicitly >>> non-dependent. >>> >> Move that statement to the rational. It's an operational concern, not a >> policy issue. >> >>>> 5.2.7 should also be removed. The policy can be retired by a proposal >>>> that >>>> achieves community consensus. There is no need for an auto- >>>> expiry process that is optional at the discretion of staff. >>> >>> How much effort is expended on policy cleanup for unused sections? >>> >> A fair amount, actually. I don't think that there are many, if any unused >> or obsolete sections currently in the NRPM and there have been several >> proposals which have removed them just in my tenure so far on the AC (a >> little more than 4 years) and many more in the decade+ that I have been >> active in the policy process. >> >>> Without active interest, I dont expect such a proposal to ever show up, >>> unless the ARIN staff solicits one for disuse. So in that case, let them >>> just remove it at that point. >>> >> In the past, we have generally eschewed sunset clauses. As such, I don't >> think having one in this policy is particularly more desirable than any >> of the past cases where the community has opted not to put one in. >> >>> Also not a pivotal aspect of the proposal. >>> >>> >>>> I don't believe this policy will do anything to achieve the objective >>>> stated >>>> in the title, however, perhaps that is because I cannot decipher 5.2.3. >>>> If the author manages to sufficiently clarify 5.2.3 and/or modify the >>>> policy >>>> such that it would demonstrably achieve the titled objective, I would >>>> support that objective. >>>> >>>> Otherwise, it just looks like an attempt to back-door ASN transfers >>>> which >>>> I oppose. >>>> >>>> >>>> Owen >>> >>> The proposal was written with the expectation that directed ASN >>> transfers are likely to be allowed via policy sometime soon, it is not >>> intended to allow or disallow them on its own, except to add this >>> additional restriction, applicable ONLY inasmuch as an ASN transfer is >>> allowed, either via 8.2 currently or as 8.3 might be amended. >>> >> Then it should say that. The proposal for ASN transfers is >> (unfortunately) in last call, but, it has not been recommended to the >> board for adoption, let alone been adopted. >> >> Owen >> >> >> > _______________________________________________ > 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 kkargel at polartel.com Mon May 7 11:06:12 2012 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 7 May 2012 10:06:12 -0500 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: <5E23819DB192BE43A083C3740C0EF7821FA2EF10@S-ITSV-MBX01P.ead.ubc.ca> <1A2546DA-CC66-49DA-A292-B91A590F3924@corp.arin.net> <52BB16C6-1CAD-4D55-B8DA-96149547A6CE@arin.net> <74CB4F6F-5266-4723-A753-205164A7F056@arin.net> <7AA8C630-DDBD-4B80-B72B-B6BCC8C48316@arin.net> <113D2991-1AF2-4E62-8851-69B5494C653E@arin.net> <08C000EB-091A-44D6-B6CE-D8C9DD0E43EE@arin.net> Message-ID: <8695009A81378E48879980039EEDAD28012075D312@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of William Herrin > Sent: Friday, May 04, 2012 9:06 PM > To: David Krumme > Cc: ARIN PPML > Subject: Re: [arin-ppml] Clarify /29 assignment identification requirement > > On 5/4/12, David Krumme wrote: > >> I would think that any indirect evidence of a customer's existence > >> would support the address utilization claim. A bank statement listing > >> deposits and charges. > > > > Our bank statement shows all sources of our income and would not in any > > way tend to either validate or discredit our ISP activities. > > Hi David, > > It would demonstrate a plausible customer count (or the lack thereof) > for the address utilization you claimed. > > > >> A demonstration of access to the routers implied > >> by assignment claims with apparent programming and interface statuses > >> that match. > > > > I am not going to allow access to our routers to anyone out there on the > > Internet, out of security as well as trade secret concerns. Sorry. > > I believe the suggestion was for a webex session in which an ARIN rep > on the phone asks you to operate the router and then observes > (read-only) the result. [kjk] I would tend to also be hesitant to have someone watch over my shoulder as I did things like listing router configs showing detailed network infrastructure, passwords, secrets, (encrypted or not) etc.. Video screen capture for replay of a webex session is trivial, decrypting cisco passwords from config listings is also trivial, getting clear text from a cisco type 7 password takes less than a minute for a casual admin.. There are better ways to protect things, but this example works for this discussion. While I trust ARIN in general there are just some things that one doesn't do, and exposing critical core configurations is one of them. Telecommunications carriers in particular are under a lot of regulations that are vaguely written and have HUGE gray areas that may be impacted my releasing customer identification data tied to networking. Even things like CPNI regulations that are primarily aimed at telephone data could possibly be construed to apply to data referring to a telephone/data customer of a telephone carrier. Hopefully everyone has the "ok to disclose to necessary third parties" type of clause built in to their contracts. Exposing customer data for retention in a third party database is definitely something to be avoided if at all possible. Kevin > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4935 bytes Desc: not available URL: From ppml at rs.seastrom.com Mon May 7 16:12:55 2012 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 07 May 2012 16:12:55 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: (Owen DeLong's message of "Fri, 4 May 2012 12:20:05 -0700") References: <1120503122722.977P-100000@Ives.egh.com> Message-ID: <868vh3eomw.fsf@seastrom.com> >> On the other hand, the AC paying attention to and _respecting_ >> minority dissent within the community is long overdue. I don't >> understand the dissent on this one. But since it exists, what's rush >> to get the policy on the books? Let's talk about it some more first. > > As part of that dissent, and as a frequent dissenter in AC > decisions, I cannot abide your characterization of the AC here. > ... > I cannot disclose details, but, I can assure you that AC meetings are not > a rubber stamp process and that there is often spirited debate amongst > us covering all sides prior to taking action on policy proposals. The details of AC meetings are a matter of public record and are published in the AC's meeting minutes for all to see at: https://www.arin.net/about_us/ac/index.html The AC not only pays attention to and respects minority points of view, but we _go out of our way to consider them_. It sounds as if Mr. Herrin believes that a whiff of dissent ought to be a cue for a bad case of analysis paralysis. I for one disagree. -r From bill at herrin.us Mon May 7 17:29:31 2012 From: bill at herrin.us (William Herrin) Date: Mon, 7 May 2012 17:29:31 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <868vh3eomw.fsf@seastrom.com> References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> Message-ID: On 5/7/12, Robert E. Seastrom wrote: > The AC not only pays attention to and respects minority points of > view, but we _go out of our way to consider them_. It sounds as if > Mr. Herrin believes that a whiff of dissent ought to be a cue for a > bad case of analysis paralysis. I for one disagree. Robert, Yes, the AC carefully considers dissenting viewpoints before classifying them as wrong or otherwise unworthy of inclusion. If you want the community to own the policies then a non-trivial amount of dissent means you keep discussing it. That's the nature of consensus and if you want the disparate members of the community to engage as ARIN's partners in address management, that's what it takes. If community input in to the policies is important but community ownership of the resulting policies is not, then you can push policies over objections based on expert analysis. However, that eventually sets ARIN up for an adversarial relationship with the community rather than a cooperative one. The folks who internalize rules set by 15 people on a committee are largely comprised of the 15 people on the committee. If that many. I cast too wide a net when I disparaged the entire AC for incautiously pushing past dissent. Fact is several of the folks on the AC have been doing their level headed best to be broadly inclusive. By doing things like voting to keep the instant proposal in discussion due to the significant dissent. To them I tip my hat. Sadly you're not a voting majority. But keep trying; it's worth the fight. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Mon May 7 20:18:05 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 7 May 2012 17:18:05 -0700 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> Message-ID: <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> On May 7, 2012, at 2:29 PM, William Herrin wrote: > On 5/7/12, Robert E. Seastrom wrote: >> The AC not only pays attention to and respects minority points of >> view, but we _go out of our way to consider them_. It sounds as if >> Mr. Herrin believes that a whiff of dissent ought to be a cue for a >> bad case of analysis paralysis. I for one disagree. > > Robert, > > Yes, the AC carefully considers dissenting viewpoints before > classifying them as wrong or otherwise unworthy of inclusion. > Bill, I think you are drawing an utterly unfair conclusion here and stating it as fact. > If you want the community to own the policies then a non-trivial > amount of dissent means you keep discussing it. That's the nature of > consensus and if you want the disparate members of the community to > engage as ARIN's partners in address management, that's what it takes. While having true consensus would be ideal, it's not always feasible. In some cases, the AC has to weigh whether failing to move a proposal with significant support forward would do a greater harm than continuing to discuss it. It is a valid criticism that there has been some tendency towards a tyranny of the majority of late and that the AC has trended in some cases towards mistaking majority support for consensus. However, even in times of such errors, I do not feel that the AC has discounted, ignored, or otherwise disenfranchised any dissenting views presented in the public record. > If community input in to the policies is important but community > ownership of the resulting policies is not, then you can push policies > over objections based on expert analysis. However, that eventually > sets ARIN up for an adversarial relationship with the community rather > than a cooperative one. The folks who internalize rules set by 15 > people on a committee are largely comprised of the 15 people on the > committee. If that many. Community ownership is definitely important and I challenge you to provide specific examples of "pushing policies over objections based on expert analysis". The last sentence just doesn't parse for me, so I'm not sure what you were intending to say. > I cast too wide a net when I disparaged the entire AC for incautiously > pushing past dissent. Fact is several of the folks on the AC have been > doing their level headed best to be broadly inclusive. By doing things > like voting to keep the instant proposal in discussion due to the > significant dissent. To them I tip my hat. Sadly you're not a voting > majority. But keep trying; it's worth the fight. I don't know which side of that divider you would cast me on. I suspect that there have been instances where I could land on either side, depending on the proposal in question. I know that I voted to abandon some proposals that you held dear early in the process. In each of those cases, failing to abandon would have left the proposal in limbo for another policy cycle without providing the option to petition. Since the proposals were pretty strongly opposed on the list and had minimal support, I felt the most honest thing to do at the time was abandon and let you petition if you felt strongly about them. In any case, I do not take my voting responsibilities on the AC lightly and I believe that the AC has consistently acted in good faith as a body to achieve what we truly believed was the most desirable outcome for the community. (I define most desirable as a combination of factors, including will of the community, technical soundness, usefulness of the policy/proposal, preservation of good stewardship of resources, etc.) Owen From bill at herrin.us Mon May 7 21:25:42 2012 From: bill at herrin.us (William Herrin) Date: Mon, 7 May 2012 21:25:42 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> Message-ID: On 5/7/12, Owen DeLong wrote: > On May 7, 2012, at 2:29 PM, William Herrin wrote: >> If you want the community to own the policies then a non-trivial >> amount of dissent means you keep discussing it. That's the nature of >> consensus and if you want the disparate members of the community to >> engage as ARIN's partners in address management, that's what it takes. > > While having true consensus would be ideal, it's not always feasible. > In some cases, the AC has to weigh whether failing to move a proposal > with significant support forward would do a greater harm than continuing > to discuss it. Hi Owen, Would failing to move an AS transfer proposal forward this cycle do harm? We've survived without one for 15 years and we're not sort of AS numbers, at least not the 32 bit variety. > It is a valid criticism that there has been some tendency towards a tyranny > of the majority of late and that the AC has trended in some cases towards > mistaking majority support for consensus. However, even in times of such > errors, I do not feel that the AC has discounted, ignored, or otherwise > disenfranchised any dissenting views presented in the public record. If I have overstated the case, well, it wouldn't be the first time. But from your own words, you see the problem too. >> The folks who internalize rules set by 15 >> people on a committee are largely comprised of the 15 people on the >> committee. > > The last sentence just doesn't parse for me, so I'm not sure what you > were intending to say. When folks are confident that the rules were made with their consent, they're less likely to deliberately cheat. 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 May 7 21:42:54 2012 From: bill at herrin.us (William Herrin) Date: Mon, 7 May 2012 21:42:54 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> Message-ID: On 5/7/12, Bill Darte wrote: > On Mon, May 7, 2012 at 2:29 PM, William Herrin wrote: >> I cast too wide a net when I disparaged the entire AC for incautiously >> pushing past dissent. Fact is several of the folks on the AC have been >> doing their level headed best to be broadly inclusive. By doing things >> like voting to keep the instant proposal in discussion due to the >> significant dissent. To them I tip my hat. Sadly you're not a voting >> majority. But keep trying; it's worth the fight. > > Sadly, I believe you identify support for your point of view as a > qualification for being on the AC. Bill, If by "my point of view" you mean my views on whether a policy should or shouldn't pass, this very discussion gives the lie to such a notion. I think the proposed AS transfer policy is A-OK and would like to see it or a comparable proposal become policy. And I have said so. Yet I argue against the last call on the grounds that too much dissent remains. If by "my point of view" you mean my views on the lengths to which an AC member should enthusiastically go to draw dissenters into a consensus before sending a policy draft to the board, you're darn right I consider it a qualification for being on the AC. And by that standard too few of you are well qualified. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Mon May 7 22:07:44 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 7 May 2012 19:07:44 -0700 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> Message-ID: <4B108867-1F42-4DCC-BB9F-74BFC192BC14@delong.com> On May 7, 2012, at 6:25 PM, William Herrin wrote: > On 5/7/12, Owen DeLong wrote: >> On May 7, 2012, at 2:29 PM, William Herrin wrote: >>> If you want the community to own the policies then a non-trivial >>> amount of dissent means you keep discussing it. That's the nature of >>> consensus and if you want the disparate members of the community to >>> engage as ARIN's partners in address management, that's what it takes. >> >> While having true consensus would be ideal, it's not always feasible. >> In some cases, the AC has to weigh whether failing to move a proposal >> with significant support forward would do a greater harm than continuing >> to discuss it. > > Hi Owen, > > Would failing to move an AS transfer proposal forward this cycle do > harm? We've survived without one for 15 years and we're not sort of AS > numbers, at least not the 32 bit variety. > IMHO, no, but, there are those that disagree with me and legitimately so in this regard. You will note from the draft minutes that I voted against moving that proposal forward. > >> It is a valid criticism that there has been some tendency towards a tyranny >> of the majority of late and that the AC has trended in some cases towards >> mistaking majority support for consensus. However, even in times of such >> errors, I do not feel that the AC has discounted, ignored, or otherwise >> disenfranchised any dissenting views presented in the public record. > > If I have overstated the case, well, it wouldn't be the first time. > But from your own words, you see the problem too. > > >>> The folks who internalize rules set by 15 >>> people on a committee are largely comprised of the 15 people on the >>> committee. >> >> The last sentence just doesn't parse for me, so I'm not sure what you >> were intending to say. > > When folks are confident that the rules were made with their consent, > they're less likely to deliberately cheat. > Agreed. One of the reasons I try to encourage participation by the broadest possible community. I also find that to the extent one can remove greed as a motivator to break the rules, you gain greater compliance. Hence my general opposition to transfer policies outside of the immediate (and temporary) exigent need for an IPv4 transfer policy which I remain ambivalent at best about. Owen From bill at herrin.us Tue May 8 00:40:40 2012 From: bill at herrin.us (William Herrin) Date: Tue, 8 May 2012 00:40:40 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <4B108867-1F42-4DCC-BB9F-74BFC192BC14@delong.com> References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> <4B108867-1F42-4DCC-BB9F-74BFC192BC14@delong.com> Message-ID: On 5/7/12, Owen DeLong wrote: > On May 7, 2012, at 6:25 PM, William Herrin wrote: >> When folks are confident that the rules were made with their consent, >> they're less likely to deliberately cheat. > > Agreed. One of the reasons I try to encourage participation by the broadest > possible community. Come to think of it, I wonder if this doesn't reflect a deficiency in the PDP itself. We talk and talk about the wonder of community consensus policy, but consensus is a progression of dissonant ideas into a coherent plan with mass appeal. No such progression is present in the PDP... from first to last it's a majority vote. Perhaps it shouldn't be. Maybe instead: 4 affirmatives accept a proposal onto the docket and move it to formal discussion 8 affirmatives move a discussed proposal to last call 12 affirmatives send a called proposal to the board. We can talk the talk about consensus, but such with such a progression it'd be hard to avoid walking the walk. 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 Tue May 8 08:41:54 2012 From: jcurran at arin.net (John Curran) Date: Tue, 8 May 2012 12:41:54 +0000 Subject: [arin-ppml] Consensus development for policy (was: Re: ARIN-2012-3: ASN Transfers - Last Call) In-Reply-To: References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> <4B108867-1F42-4DCC-BB9F-74BFC192BC14@delong.com> Message-ID: <9D82E8CA-35BB-4AC6-83B9-8A63EEDECBED@corp.arin.net> On May 7, 2012, at 11:40 PM, William Herrin wrote: > Come to think of it, I wonder if this doesn't reflect a deficiency in > the PDP itself. > > We talk and talk about the wonder of community consensus policy, but > consensus is a progression of dissonant ideas into a coherent plan > with mass appeal. No such progression is present in the PDP... from > first to last it's a majority vote. The intent is that views which are not in the majority are at least fully discussed and documented so that any insights or perspectives added can be considered by everyone and potentially be incorporated into the overall consensus position if well-supported. This is fairly important aspect of building consensus and the proposed revision to the PDP (sent out for community consultation in September 2011) call this out more explicitly - "A strong level of community support for a policy change does not mean unanimous; it may be supported by only a subset of the community, as long as the policy change enjoys substantially more support than opposition in the community active in the discussion. Furthermore, any specific concerns expressed by a significant portion of the community must have been explicitly considered by the ARIN AC in their assessment of the policy change." When such explicit recognition of minority positions is combined with active agreement seeking, consensus results are more likely. > Perhaps it shouldn't be. Maybe instead: > > 4 affirmatives accept a proposal onto the docket and move it to formal > discussion > 8 affirmatives move a discussed proposal to last call > 12 affirmatives send a called proposal to the board. > > We can talk the talk about consensus, but such with such a progression > it'd be hard to avoid walking the walk. It is important that the decision rule to formally recommend policy needs to have a higher threshold than simple majority, or you can end up with oscillations between closely contested positions based on small variations in participation. Having several tiers of thresholds based on maturity is also an option, and should be discussed more by this community. As I noted at the Vancouver meeting, we have finished incorporating feedback from the PDP consultation into a revised PDP Update and will be sending those documents out for community consultation shortly. Thanks for raising this important issue! /John John Curran President and CEO ARIN From farmer at umn.edu Tue May 8 09:27:25 2012 From: farmer at umn.edu (David Farmer) Date: Tue, 08 May 2012 08:27:25 -0500 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> Message-ID: <4FA91F3D.3080100@umn.edu> On 5/7/12 20:25 CDT, William Herrin wrote: > On 5/7/12, Owen DeLong wrote: >> On May 7, 2012, at 2:29 PM, William Herrin wrote: >>> If you want the community to own the policies then a non-trivial >>> amount of dissent means you keep discussing it. That's the nature of >>> consensus and if you want the disparate members of the community to >>> engage as ARIN's partners in address management, that's what it takes. >> >> While having true consensus would be ideal, it's not always feasible. >> In some cases, the AC has to weigh whether failing to move a proposal >> with significant support forward would do a greater harm than continuing >> to discuss it. > > Hi Owen, > > Would failing to move an AS transfer proposal forward this cycle do > harm? We've survived without one for 15 years and we're not sort of AS > numbers, at least not the 32 bit variety. Bill, You and others have mostly convinced me that we should hold off and bring this one back to the next policy meeting. However, I have a fear that we are going to be right back where we are today in 5 to 6 months after the Dallas PPM. I really don't want to repeat what happened with IPv4 transfers, were the more we discussed this issue the more the community polarized and fractured. How does the community come to a stronger consensus one way or the other? There are really only a few minor tweaks that have been proposed to the text and no one has said that those change would fundamentally change their support one way or the other. So, I don't think here are changes to the text that will significantly change the consensus. This is a major change and I think most everyone agrees that it is, this is why I believe it is OK to take a little more time. You are right, there should be no rush to make this change. However, how does the community use the extra time you are advocating for in a constructive manner? How does the community develop a stronger consensus one way or the other? Is more time going to accomplish that? If my fears are correct and we don't succeed in producing a stronger consensus either way, would you advocate a third policy cycle? Is the dissent strong enough and significant enough to block this proposal, even though it seems that a strong majority supports the proposal? John is right consensus isn't unanimity; I've been doing some reading on consensus based decision making, paradoxically, dissent is part of a healthy consensus. The lack of dissent can be "evidence of intimidation, lack of imagination, lack of courage, failure to include all voices, or deliberate exclusion of the contrary views," rather than actual consensus. http://en.wikipedia.org/wiki/Consensus_decision-making -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From jcurran at arin.net Tue May 8 09:47:29 2012 From: jcurran at arin.net (John Curran) Date: Tue, 8 May 2012 13:47:29 +0000 Subject: [arin-ppml] Regarding consensus-based policy development (Re: ARIN-2012-3: ASN Transfers - Last Call) In-Reply-To: <4FA91F3D.3080100@umn.edu> References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> <4FA91F3D.3080100@umn.edu> Message-ID: <3909997B-BA30-49EA-93C9-4E3E3745A6AE@corp.arin.net> On May 8, 2012, at 8:27 AM, David Farmer wrote: > > John is right consensus isn't unanimity; I've been doing some reading on consensus based decision making, paradoxically, dissent is part of a healthy consensus. > The lack of dissent can be "evidence of intimidation, lack of imagination, lack of courage, failure to include all voices, or deliberate exclusion of the contrary views," rather than actual consensus. Regarding deliberative consensus-based policy development, it's essential that folks take the time to explain the benefits or concerns that they foresee with any given policy change in addition to simply expressing if they are in support or opposed. It is through the expression of these concerns or benefits that the community as a whole improves its understanding. As various policy proposals may only directly affect a subset of the community (e.g. web hosting policy, residential privacy policy, etc), it is the elaboration on the concerns and benefits through simple explanation that brings us all to common understanding, if not agreement. The Advisory Council has the challenging job of considering this reasoning (both in favor and opposed) when making sure that proposed policy is technically sound and supported by the community. Thanks! /John John Curran President and CEO ARIN From bill at herrin.us Tue May 8 10:09:46 2012 From: bill at herrin.us (William Herrin) Date: Tue, 8 May 2012 10:09:46 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> <4B108867-1F42-4DCC-BB9F-74BFC192BC14@delong.com> Message-ID: On 5/8/12, Bill Darte wrote: > On Mon, May 7, 2012 at 9:40 PM, William Herrin wrote: > >> On 5/7/12, Owen DeLong wrote: >> > On May 7, 2012, at 6:25 PM, William Herrin wrote: >> >> When folks are confident that the rules were made with their consent, >> >> they're less likely to deliberately cheat. >> > >> > Agreed. One of the reasons I try to encourage participation by the >> broadest >> > possible community. >> >> >> Come to think of it, I wonder if this doesn't reflect a deficiency in >> the PDP itself. >> >> We talk and talk about the wonder of community consensus policy, but >> consensus is a progression of dissonant ideas into a coherent plan >> with mass appeal. No such progression is present in the PDP... from >> first to last it's a majority vote. >> >> Perhaps it shouldn't be. Maybe instead: >> >> 4 affirmatives accept a proposal onto the docket and move it to formal >> discussion >> 8 affirmatives move a discussed proposal to last call >> 12 affirmatives send a called proposal to the board. >> > > What of a situation where 10 of 15 members of the AC are in favor of > sending a proposal to the board and yet the was 59 posts on PPML where 16 > were in favor and 3 opposed...and in the PPM of 139 persons in the room, 37 > were in favor and 13 against. > > What should the AC do? > > If your answer is....it depends, then that is the right answer and the AC > is elected to do so....IMO. Hi Bill, One nice feature of my straw-man-for-discussion above is that it gives the AC relatively clear guidance. 10 doesn't meet the 12 vote threshold to send it to the board. Yet it's well past the threshold for continued discussion and development. 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 Tue May 8 10:41:30 2012 From: bill at herrin.us (William Herrin) Date: Tue, 8 May 2012 10:41:30 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <4FA91F3D.3080100@umn.edu> References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> <4FA91F3D.3080100@umn.edu> Message-ID: On 5/8/12, David Farmer wrote: > On 5/7/12 20:25 CDT, William Herrin wrote: >> Would failing to move an AS transfer proposal forward this cycle do >> harm? We've survived without one for 15 years and we're not sort of AS >> numbers, at least not the 32 bit variety. > > You and others have mostly convinced me that we should hold off and > bring this one back to the next policy meeting. However, I have a fear > that we are going to be right back where we are today in 5 to 6 months > after the Dallas PPM. I really don't want to repeat what happened with > IPv4 transfers, were the more we discussed this issue the more the > community polarized and fractured. > > How does the community come to a stronger consensus one way or the > other? Hi David, This is, of course, the hard part. There is no easy answer that I'm aware of, but the general approach is to look for areas in which compromise could be possible. Dissenter #1, would you consider a version in which the intended AS recipient is expected to show a technical justification for the transfer? What elements would the justification have? Would "because I'm using it on equipment that doesn't properly support 4-byte AS numbers when no 2-byte AS numbers are otherwise available" be an acceptable justification? Dissenter #2, would you consider the proposal with a sunset date, so that if your fears prove founded the onus is on the proponents to to convince folks to re-up the policy instead of on you to repleal it? If no evidence supporting those fears appears by the sunset date, could you then accept making the policy permanent? What would get you to a comfort zone where even if you don't see a driving need for the policy you could determine that it does no harm? Sure we all hate sunset dates but is that really such a hard pill to swallow when straying into the unknown? And so on. We won't get to zero dissenters; the group is too large. But we can do better than where we are with it today. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lar at mwtcorp.net Tue May 8 11:28:35 2012 From: lar at mwtcorp.net (Larry Ash) Date: Tue, 08 May 2012 09:28:35 -0600 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <4FA91F3D.3080100@umn.edu> References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> <4FA91F3D.3080100@umn.edu> Message-ID: On Tue, 08 May 2012 08:27:25 -0500 David Farmer wrote: > > > On 5/7/12 20:25 CDT, William Herrin wrote: >> On 5/7/12, Owen DeLong wrote: >>> On May 7, 2012, at 2:29 PM, William Herrin wrote: >>>> If you want the community to own the policies then a non-trivial >>>> amount of dissent means you keep discussing it. That's the nature of >>>> consensus and if you want the disparate members of the community to >>>> engage as ARIN's partners in address management, that's what it takes. >>> >>> While having true consensus would be ideal, it's not always feasible. >>> In some cases, the AC has to weigh whether failing to move a proposal >>> with significant support forward would do a greater harm than continuing >>> to discuss it. >> >> Hi Owen, >> >> Would failing to move an AS transfer proposal forward this cycle do >> harm? We've survived without one for 15 years and we're not sort of AS >> numbers, at least not the 32 bit variety. > > Bill, > > You and others have mostly convinced me that we should hold off and bring >this one back to the next policy meeting. However, I have a fear that we are >going to be right back where we are today in 5 to 6 months after the Dallas >PPM. I really don't want to repeat what happened with IPv4 transfers, were >the more we discussed this issue the more the community polarized and >fractured. > > How does the community come to a stronger consensus one way or the other? > There are really only a few minor tweaks that have been proposed to the text >and no one has said that those change would fundamentally change their >support one way or the other. So, I don't think here are changes to the text >that will significantly change the consensus. > The problem, as I see it, is that their seems to be two fundamental approaches. The "Why's" and the "Why not's". The "why's" want some concrete reason why this is necessary. An ASN is a value in a router that isn't public facing. The main reason to transfer an ASN would be to preserve existing customer configurations downstream from an organization. The unknown risk of making a "market" for ASN's seem unnecessary. The "why's" demand a reason why this risk is necessary. The "why not's" seem to view this as a market opportunity so they they can participate in the market either buying, selling, or brokering in ASN's or more fundamentally why not. Whatever the overriding purpose they see no obvious reason to oppose this so they require the "why's" to give them a reason why not. At this point neither side has been able to explain either why or why not. This seems more fundamental than the discussion at hand and probably all we can hope for is that each side with try and understand the other. Maybe with that understanding a consensuses can be reached. > This is a major change and I think most everyone agrees that it is, this is >why I believe it is OK to take a little more time. You are right, there >should be no rush to make this change. However, how does the community use >the extra time you are advocating for in a constructive manner? How does the >community develop a stronger consensus one way or the other? Is more time >going to accomplish that? > > If my fears are correct and we don't succeed in producing a stronger >consensus either way, would you advocate a third policy cycle? Is the >dissent strong enough and significant enough to block this proposal, even >though it seems that a strong majority supports the proposal? > > John is right consensus isn't unanimity; I've been doing some reading on >consensus based decision making, paradoxically, dissent is part of a healthy >consensus. > The lack of dissent can be "evidence of intimidation, lack of imagination, >lack of courage, failure to include all voices, or deliberate exclusion of >the contrary views," rather than actual consensus. > > http://en.wikipedia.org/wiki/Consensus_decision-making > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > 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 tvest at eyeconomics.com Tue May 8 11:43:28 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Tue, 8 May 2012 11:43:28 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <4FA91F3D.3080100@umn.edu> References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> <4FA91F3D.3080100@umn.edu> Message-ID: On May 8, 2012, at 9:27 AM, David Farmer wrote: > On 5/7/12 20:25 CDT, William Herrin wrote: >> On 5/7/12, Owen DeLong wrote: >>> On May 7, 2012, at 2:29 PM, William Herrin wrote: >>>> If you want the community to own the policies then a non-trivial >>>> amount of dissent means you keep discussing it. That's the nature of >>>> consensus and if you want the disparate members of the community to >>>> engage as ARIN's partners in address management, that's what it takes. >>> >>> While having true consensus would be ideal, it's not always feasible. >>> In some cases, the AC has to weigh whether failing to move a proposal >>> with significant support forward would do a greater harm than continuing >>> to discuss it. >> >> Hi Owen, >> >> Would failing to move an AS transfer proposal forward this cycle do >> harm? We've survived without one for 15 years and we're not sort of AS >> numbers, at least not the 32 bit variety. > > Bill, > > You and others have mostly convinced me that we should hold off and bring this one back to the next policy meeting. However, I have a fear that we are going to be right back where we are today in 5 to 6 months after the Dallas PPM. I really don't want to repeat what happened with IPv4 transfers, were the more we discussed this issue the more the community polarized and fractured. > > How does the community come to a stronger consensus one way or the other? There are really only a few minor tweaks that have been proposed to the text and no one has said that those change would fundamentally change their support one way or the other. So, I don't think here are changes to the text that will significantly change the consensus. > > This is a major change and I think most everyone agrees that it is, this is why I believe it is OK to take a little more time. You are right, there should be no rush to make this change. However, how does the community use the extra time you are advocating for in a constructive manner? How does the community develop a stronger consensus one way or the other? Is more time going to accomplish that? > > If my fears are correct and we don't succeed in producing a stronger consensus either way, would you advocate a third policy cycle? Is the dissent strong enough and significant enough to block this proposal, even though it seems that a strong majority supports the proposal? > > John is right consensus isn't unanimity; I've been doing some reading on consensus based decision making, paradoxically, dissent is part of a healthy consensus. > The lack of dissent can be "evidence of intimidation, lack of imagination, lack of courage, failure to include all voices, or deliberate exclusion of the contrary views," rather than actual consensus. > > http://en.wikipedia.org/wiki/Consensus_decision-making > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== If the only compelling, and unequivocally consensus-supported near-term requirement with respect to ASNs is accommodating bankruptcy-related transfers, may I suggest that we immediately develop a separate proposal that is explicitly limited to ASN transfers in that specific context? I suspect that the pursuit of consensus would be easier, and the results clearer, if options for handling "involuntary" transfers, ala bankruptcy, were separated from policies covering voluntary/strategic ASN transfer interests. It's an empirical question -- but I assume there are ways to gauge whether and how the distribution of opinions on ASN transfers would change given the option of addressing "involuntary" vs. "voluntary" transfers separately...? TV From michael+ppml at burnttofu.net Tue May 8 12:06:29 2012 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Tue, 08 May 2012 09:06:29 -0700 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <4FA91F3D.3080100@umn.edu> References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> <4FA91F3D.3080100@umn.edu> Message-ID: <4FA94485.1060309@burnttofu.net> On 5/8/12 6:27 AM, David Farmer wrote: > How does the community come to a stronger consensus one way or the > other? There are really only a few minor tweaks that have been proposed > to the text and no one has said that those change would fundamentally > change their support one way or the other. So, I don't think here are > changes to the text that will significantly change the consensus. I, for one, would support a policy that limited ASN transfers to bankruptcy proceedings, in addition to the M&A transfers already allowed. michael From jcurran at arin.net Tue May 8 12:21:29 2012 From: jcurran at arin.net (John Curran) Date: Tue, 8 May 2012 16:21:29 +0000 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> <4FA91F3D.3080100@umn.edu> Message-ID: <7E032F78-C253-4948-8B1C-02E2EFEEEDB3@corp.arin.net> On May 8, 2012, at 9:41 AM, William Herrin wrote: > Dissenter #1, would you consider a version in which the intended AS > recipient is expected to show a technical justification for the > transfer? What elements would the justification have? Would "because > I'm using it on equipment that doesn't properly support 4-byte AS > numbers when no 2-byte AS numbers are otherwise available" be an > acceptable justification? Note that present technical justification for an AS number is based on verification that the organization meets one of the following: ? A unique routing policy (its policy differs from its border gateway peers) ? A multihomed site. Under 2012-3 as written, this requirement would continue apply, although it is generally acknowledged to be a fairly low bar to meet. I believe that you are suggesting the possibility of an additional technical requirement which would apply solely for ASN transfers. I have no view on this option, but wanted to make sure that the current technical requirements for ASN issuance are noted in this discussion. > Dissenter #2, would you consider the proposal with a sunset date, so > that if your fears prove founded the onus is on the proponents to to > convince folks to re-up the policy instead of on you to repleal it? If > no evidence supporting those fears appears by the sunset date, could > you then accept making the policy permanent? What would get you to a > comfort zone where even if you don't see a driving need for the policy > you could determine that it does no harm? > > Sure we all hate sunset dates but is that really such a hard pill to > swallow when straying into the unknown? Sunset dates are indeed possible in policy, but do also set us up for precipitous uncertainty unless there is an shared understanding of the potential risks that are being hedged against. In this manner, as the deadline approaches, everyone has some common understanding of some of the issues that to be reviewed in the policy discussions on that will inevitably occur approaching sunset. This is consideration in thinking about using sunset clauses in policy (since we generally want to avoid uncertainty in number resource policy), but folks should feel free to specify them if it makes for better policy. > And so on. We won't get to zero dissenters; the group is too large. > But we can do better than where we are with it today. Full agreement and thanks for encouraging discussion! /John John Curran President and CEO ARIN From lea.roberts at stanford.edu Tue May 8 12:36:55 2012 From: lea.roberts at stanford.edu (Lea Roberts) Date: Tue, 8 May 2012 09:36:55 -0700 (PDT) Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <4FA94485.1060309@burnttofu.net> References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> <4FA91F3D.3080100@umn.edu> <4FA94485.1060309@burnttofu.net> Message-ID: I agree with Michael... I am opposed to this policy as currently written but would support it with this modification. /Lea On Tue, 8 May 2012, Michael Sinatra wrote: > On 5/8/12 6:27 AM, David Farmer wrote: > >> How does the community come to a stronger consensus one way or the >> other? There are really only a few minor tweaks that have been proposed >> to the text and no one has said that those change would fundamentally >> change their support one way or the other. So, I don't think here are >> changes to the text that will significantly change the consensus. > > I, for one, would support a policy that limited ASN transfers to > bankruptcy proceedings, in addition to the M&A transfers already allowed. > > michael > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From owen at delong.com Tue May 8 12:53:41 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 8 May 2012 09:53:41 -0700 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> <4FA91F3D.3080100@umn.edu> Message-ID: On May 8, 2012, at 8:43 AM, Tom Vest wrote: > > If the only compelling, and unequivocally consensus-supported near-term requirement with respect to ASNs is accommodating bankruptcy-related transfers, may I suggest that we immediately develop a separate proposal that is explicitly limited to ASN transfers in that specific context? I suspect that the pursuit of consensus would be easier, and the results clearer, if options for handling "involuntary" transfers, ala bankruptcy, were separated from policies covering voluntary/strategic ASN transfer interests. It's an empirical question -- but I assume there are ways to gauge whether and how the distribution of opinions on ASN transfers would change given the option of addressing "involuntary" vs. "voluntary" transfers separately...? > +1 Owen From JOHN at egh.com Tue May 8 13:36:55 2012 From: JOHN at egh.com (John Santos) Date: Tue, 8 May 2012 13:36:55 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: Message-ID: <1120508132932.388C-100000@Ives.egh.com> I would also support this, though I wonder about its utility. Currently, aren't bankruptcy sales of network assets covered under M&A? After all, it's just an acquisition where the sale part was ordered by the bankruptcy court or receiver or whoever. If the network assets include routers, circuits, customers, IP addresses and ASNs, and are being sold as a single lot (or perhaps multiple lots divided geographically), that would be a perfectly normal 8.2 acquisition. If the network assests were broken down such that the ASN(s) were sold separately, who would buy them, when you can get them cheaper directly from ARIN? On Tue, 8 May 2012, Owen DeLong wrote: > > On May 8, 2012, at 8:43 AM, Tom Vest wrote: > > > > > If the only compelling, and unequivocally consensus-supported near-term requirement with respect to ASNs is accommodating bankruptcy-related transfers, may I suggest that we immediately develop a separate proposal that is explicitly limited to ASN trans > fers in that specific context? I suspect that the pursuit of consensus would be easier, and the results clearer, if options for handling "involuntary" transfers, ala bankruptcy, were separated from policies covering voluntary/strategic ASN transfer intere > sts. It's an empirical question -- but I assume there are ways to gauge whether and how the distribution of opinions on ASN transfers would change given the option of addressing "involuntary" vs. "voluntary" transfers separately...? > > > > +1 > > Owen > > _______________________________________________ > 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. > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From info at arin.net Tue May 8 14:34:50 2012 From: info at arin.net (ARIN) Date: Tue, 08 May 2012 14:34:50 -0400 Subject: [arin-ppml] =?windows-1252?q?ICANN_Board_Ratifies_=22Global_Polic?= =?windows-1252?q?y_Proposal_for_Post_Exhaustion_IPV4_Allocation_Mechanism?= =?windows-1252?q?s_by_the_IANA=94?= Message-ID: <4FA9674A.6090500@arin.net> On 6 May the ICANN Board ratified the global proposal GPP-IPv4-2011, identified in the ARIN region as ARIN-2011-9 (Global Proposal) . You can find the ICANN Board resolution at the following link: http://www.icann.org/en/groups/board/documents/resolutions-06may12-en.htm#1.1 Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From gary.buhrmaster at gmail.com Tue May 8 16:29:59 2012 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Tue, 8 May 2012 20:29:59 +0000 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <1120508132932.388C-100000@Ives.egh.com> References: <1120508132932.388C-100000@Ives.egh.com> Message-ID: On Tue, May 8, 2012 at 5:36 PM, John Santos wrote: > I would also support this, though I wonder about its utility. > > Currently, aren't bankruptcy sales of network assets covered under M&A? I would have thought so. But, as I recall, the original ARIN staff evaluation said that consul indicated that this would facilitate certain bankruptcy proceedings, so clearly there are edge cases. I would support a modified proposal that deals with the bankruptcy case. Gary From michael+ppml at burnttofu.net Tue May 8 17:07:09 2012 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Tue, 08 May 2012 14:07:09 -0700 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <1120508132932.388C-100000@Ives.egh.com> Message-ID: <4FA98AFD.4070200@burnttofu.net> On 5/8/12 1:29 PM, Gary Buhrmaster wrote: > On Tue, May 8, 2012 at 5:36 PM, John Santos wrote: >> I would also support this, though I wonder about its utility. >> >> Currently, aren't bankruptcy sales of network assets covered under M&A? > > I would have thought so. But, as I recall, the original ARIN > staff evaluation said that consul indicated that this would > facilitate certain bankruptcy proceedings, so clearly there > are edge cases. > > I would support a modified proposal that deals with the > bankruptcy case. Apparently 8.2 doesn't account for the case where "assets" are being split up in a bankruptcy proceeding. michael From scottleibrand at gmail.com Tue May 8 17:20:39 2012 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 8 May 2012 16:20:39 -0500 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <4FA98AFD.4070200@burnttofu.net> References: <1120508132932.388C-100000@Ives.egh.com> <4FA98AFD.4070200@burnttofu.net> Message-ID: On Tue, May 8, 2012 at 4:07 PM, Michael Sinatra wrote: > On 5/8/12 1:29 PM, Gary Buhrmaster wrote: > > On Tue, May 8, 2012 at 5:36 PM, John Santos wrote: > >> I would also support this, though I wonder about its utility. > >> > >> Currently, aren't bankruptcy sales of network assets covered under M&A? > > > > I would have thought so. But, as I recall, the original ARIN > > staff evaluation said that consul indicated that this would > > facilitate certain bankruptcy proceedings, so clearly there > > are edge cases. > > > > I would support a modified proposal that deals with the > > bankruptcy case. > > Apparently 8.2 doesn't account for the case where "assets" are being > split up in a bankruptcy proceeding. > As currently written, 8.2 requires "evidence that the new entity has acquired assets that used the transferred resources from the current registrant." So it very specifically requires that the number resources stay with the network. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue May 8 20:31:45 2012 From: farmer at umn.edu (David Farmer) Date: Tue, 08 May 2012 19:31:45 -0500 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: <4FA9BAF1.5080303@umn.edu> So far there has only been one last call comment on this Draft Policy, and that was from the author of the associated policy proposal. However, I and I'm sure other AC members too, would appreciate any additional last call comments the community may have regarding this Draft Policy. Even if that is simply to reaffirm your support or lack of support for this Draft Policy. Thanks. On 4/30/12 12:18 CDT, 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-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 -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bill at herrin.us Tue May 8 20:42:58 2012 From: bill at herrin.us (William Herrin) Date: Tue, 8 May 2012 20:42:58 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> <4B108867-1F42-4DCC-BB9F-74BFC192BC14@delong.com> Message-ID: On 5/8/12, Bill Darte wrote: > On Tue, May 8, 2012 at 7:09 AM, William Herrin wrote: >> On 5/8/12, Bill Darte wrote: >> > On Mon, May 7, 2012 at 9:40 PM, William Herrin wrote: >> >> Perhaps it shouldn't be. Maybe instead: >> >> >> >> 4 affirmatives accept a proposal onto the docket and move it to formal >> >> discussion >> >> 8 affirmatives move a discussed proposal to last call >> >> 12 affirmatives send a called proposal to the board. >> >> >> > >> > What of a situation where 10 of 15 members of the AC are in favor of >> > sending a proposal to the board and yet the was 59 posts on PPML where >> > 16 >> > were in favor and 3 opposed...and in the PPM of 139 persons in the >> > room, >> 37 >> > were in favor and 13 against. >> > >> > What should the AC do? >> One nice feature of my straw-man-for-discussion above is that it gives >> the AC relatively clear guidance. 10 doesn't meet the 12 vote >> threshold to send it to the board. Yet it's well past the threshold >> for continued discussion and development. > My point in asking, Bill, was to illustrate that even though the AC fails > to get the super majority vote you posit, does not mean that the other > measurable inputs of PPML and PPM could display a majority that the > community would find compelling and....still, the AC has the duty to do the > 'right thing'.... Hi Bill, The draft you describe starts with 16% opposition on the list, degrades to 26% opposition by the time it reaches the meeting and exhibits 33% opposition during the AC's subsequent vote. That's a compelling pattern all right: whatever the adjustments or issues were, they moved the draft steadily away from consensus. 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 Tue May 8 23:20:57 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 8 May 2012 22:20:57 -0500 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <1120503122722.977P-100000@Ives.egh.com> <868vh3eomw.fsf@seastrom.com> <7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com> <4FA91F3D.3080100@umn.edu> Message-ID: On 5/8/12, Larry Ash wrote: > On Tue, 08 May 2012 08:27:25 -0500 > The problem, as I see it, is that their seems to be two fundamental > approaches. The "Why's" > and the "Why not's". "Why Not" is not good enough. All policies require a rationale. All policies have a cost to implement. Time and resources of ARIN and ARIN staff have to be consumed by every policy, that could be more usefully spent on other work. Every transfer to specified recipients request. Every paragraph added to the NRPM. And indeed, unknown costs to the community in the form of unknown risks of creating a market. There must be a significantly better reason to add policy text and additional ARIN functions that require new policies, procedures, and new work for ARIN, than "Because we can". ARIN's role is stewardship of resources, not abrogation of stewardship to markets. No bonafide use case for ASN transfer to specified recipients has really been shown in this discussion. There is not compelling reason shown to add ASN transfers to specified recipients as an ARIN function, consuming ARIN resources and ARIN members' cash, like there is with IPv4 transfers. > The "why's" want some concrete reason why this is necessary. An ASN is a > value in a router that isn't public facing. The main reason to transfer an ASN would be > to preserve existing customer configurations downstream from an organization. The Transfer in case of merger/acquisition of another organization's network is covered by existing policy, and does not require transfer to specified recipients. > unknown risk of making a "market" for ASN's seem unnecessary. The "why's" demand a reason why this risk is necessary. > The "why not's" seem to view this as a market opportunity so they they can participate > in the market either buying, selling, or brokering in ASN's or more fundamentally why not. > Whatever the overriding purpose they see no obvious reason to oppose this so they > require the "why's" to give them a reason why not. > > At this point neither side has been able to explain either why or why not. > This seems more fundamental than the discussion at hand and probably all we > > can hope for is that each side with try and understand the other. Maybe with that > understanding a consensuses can be reached. -- -JH From bill at herrin.us Tue May 8 23:40:48 2012 From: bill at herrin.us (William Herrin) Date: Tue, 8 May 2012 23:40:48 -0400 Subject: [arin-ppml] ARIN-2012-1: Clarifying Requirements for IPv4 Transfers - Last Call In-Reply-To: <4FA9BAF1.5080303@umn.edu> References: <4F9EC96F.8090305@arin.net> <4FA9BAF1.5080303@umn.edu> Message-ID: On 5/8/12, David Farmer wrote: > So far there has only been one last call comment on this Draft Policy, > and that was from the author of the associated policy proposal. > However, I and I'm sure other AC members too, would appreciate any > additional last call comments the community may have regarding this > Draft Policy. Even if that is simply to reaffirm your support or lack > of support for this Draft Policy. Hi David, I'm concerned that qualification of another RIR remains described as "compatible, needs-based policies" despite ARIN staff's advice that such a condition means little: any "needs based policy" with or without verifying utilization and with need projections ranging 50 years or more is deemed compatible because it is needs based. Has staff ever indicated whether "reciprocal needs-based policies" also applies to the National Internet Registries in those regions which operate with NIRs? I observe that "The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR" means that ARIN registrants competing for addresses offered at market by other ARIN registrants are placed at a distinct disadvantage with respect to qualifying for addresses versus registrants in any region which elects to apply less stringent qualifications for receiving addresses than ARIN does. At the moment I oppose the draft policy, but I would reconsider that position if I have overlooked some other protections against abuse. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From drake.pallister at duraserver.com Wed May 9 00:23:43 2012 From: drake.pallister at duraserver.com (Drake Pallister) Date: Wed, 9 May 2012 00:23:43 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call References: <1120503122722.977P-100000@Ives.egh.com><868vh3eomw.fsf@seastrom.com><7E6836D3-95FE-49CE-A0D9-60486C1C0DD8@delong.com><4FA91F3D.3080100@umn.edu> Message-ID: Hello, If an ASN or allocation is not "real property" of an assignee to be utilized as a "monetary asset" or "cash value", then when transfers are allowed or facilitated due to a bankruptcy, foreclosure, or other demise of a business; it needs to be examined if the involved transferring parties (bankrupt company, the receiver, trustee, etc) does not fold in an ASN or allocation as a value. Agreed there is an intrinsic value to ASNs or allocations, thus enhancing the potential value of a bankrupt or dead business. I'd suggest a temporary take back (guardianship) of such ASN, at least for safe keeping by ARIN so it couldn't be globed in with a company's assets (money, equipment, receivables) and then re-issued to the successor when ARIN was satisfied with the new successor. The ASN could still be allowed to function during that time frame as to not damage the bankrupt company's real operational assets like customer base, network functionality however the ASN would only be "on loan" for the protection of the bankrupt company's customers salvation. When such a bankruptcy, foreclosure or receivership was finalized, ARIN could re-issue the ASN to the successor, or return it to the original registrant should they pull out of bankruptcy (or maybe not, if the outcome looks devious). I hope I added something, or at least reinforced parts of other suggestions that had been presented, as I know how bankruptcy trustees, receivers, and lien holders tend to throw a blanket over everything attached to an insolvent company's entire structure and assume it's all part of the marketable value. If such a bankrupt company was taken over as a whole presents a completely different picture than if the company is liquidated down to their pencils, and paperclips. Respectfully, Drake Pallister ----- Original Message ----- From: "Owen DeLong" To: "Tom Vest" Cc: Sent: Tuesday, May 08, 2012 12:53 PM Subject: Re: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call > > On May 8, 2012, at 8:43 AM, Tom Vest wrote: > >> >> If the only compelling, and unequivocally consensus-supported near-term >> requirement with respect to ASNs is accommodating bankruptcy-related >> transfers, may I suggest that we immediately develop a separate proposal >> that is explicitly limited to ASN transfers in that specific context? I >> suspect that the pursuit of consensus would be easier, and the results >> clearer, if options for handling "involuntary" transfers, ala bankruptcy, >> were separated from policies covering voluntary/strategic ASN transfer >> interests. It's an empirical question -- but I assume there are ways to >> gauge whether and how the distribution of opinions on ASN transfers would >> change given the option of addressing "involuntary" vs. "voluntary" >> transfers separately...? >> > > +1 > > Owen > > _______________________________________________ > 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 Wed May 9 12:22:33 2012 From: bill at herrin.us (William Herrin) Date: Wed, 9 May 2012 12:22:33 -0400 Subject: [arin-ppml] ARIN-2012-1: Clarifying Requirements for IPv4 Transfers - Last Call In-Reply-To: References: <4F9EC96F.8090305@arin.net> <4FA9BAF1.5080303@umn.edu> Message-ID: On 5/9/12, Bill Darte wrote: > And it still says that the RIRs must agree to the transfer, giving either > RIR latitude. Which was also described by staff as non-operative. Except in cases where ARIN becomes aware that the other RIR violated its published policies, ARIN will agree to the transfer. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmaimon at chl.com Wed May 9 13:08:24 2012 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 09 May 2012 13:08:24 -0400 Subject: [arin-ppml] ARIN-2012-1: Clarifying Requirements for IPv4 Transfers - Last Call In-Reply-To: References: <4F9EC96F.8090305@arin.net> <4FA9BAF1.5080303@umn.edu> Message-ID: <4FAAA488.7000408@chl.com> William Herrin wrote: > On 5/8/12, David Farmer wrote: >> So far there has only been one last call comment on this Draft Policy, >> and that was from the author of the associated policy proposal. >> However, I and I'm sure other AC members too, would appreciate any >> additional last call comments the community may have regarding this >> Draft Policy. Even if that is simply to reaffirm your support or lack >> of support for this Draft Policy. > > Hi David, > > I'm concerned that qualification of another RIR remains described as > "compatible, needs-based policies" despite ARIN staff's advice that > such a condition means little: any "needs based policy" with or > without verifying utilization and with need projections ranging 50 > years or more is deemed compatible because it is needs based. > I supported Policy Proposal 119, believing that compatible meant that a recipient would be able to qualify for the receipt of the space under both RiR's policies. As staff has explicitly stated this is not the case, were we to still be discussing PP119, which became 2011-1, which was already recommended for adoption, and which the Board has merely delayed implementation, I would now be opposing it. For the sake of our PDP, I would like to think that the clarity of this interpretation was always present and understood by all those who supported 2011-1. But now we are discussing a draft policy that clarifies requirements for these transfers, which are already policy. So unless it somehow makes things worse and not better, then I continue to support it. Joe From bill at herrin.us Wed May 9 14:01:09 2012 From: bill at herrin.us (William Herrin) Date: Wed, 9 May 2012 14:01:09 -0400 Subject: [arin-ppml] ARIN-2012-1: Clarifying Requirements for IPv4 Transfers - Last Call In-Reply-To: <4FAAA488.7000408@chl.com> References: <4F9EC96F.8090305@arin.net> <4FA9BAF1.5080303@umn.edu> <4FAAA488.7000408@chl.com> Message-ID: On 5/9/12, Joe Maimon wrote: > But now we are discussing a draft policy that clarifies requirements for > these transfers, which are already policy. So unless it somehow makes > things worse and not better, then I continue to support it. Hi Joe, In fact these transfers are not policy today. According to https://www.arin.net/policy/proposals/2011_1.html, draft 2011-1 which proposes to create the transfers is still held under advisement by the board. I concede they're likely to adopt it despite the deficiencies. Assuming they do, I expect to concur with your reasoning here. As has been pointed out to me in times past, until the board actually does adopt a policy, follow-ons predicated on adoption of said policy are premature. 2012-1 has no caveat for inactivation should 2011-1 somehow fail to become policy. Its recommendation to last call is procedurally independent of that action. 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 Wed May 9 16:46:47 2012 From: info at arin.net (ARIN) Date: Wed, 09 May 2012 16:46:47 -0400 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy In-Reply-To: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> Message-ID: <4FAAD7B7.4050701@arin.net> ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy 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-170 Transfer of Number Resources in case of Bankruptcy Proposal Originator: Christoph Blecker Proposal Version: 1.0 Date: 9 May 2012 Policy term: permanent Policy statement: NRPM 8.4 Bankruptcy Proceedings Similar to section 8.2, ARIN will consider requests for the transfer of number resources in the case of bankruptcy or other court-supervised liquidation proceedings upon receipt of evidence that the receiving entity has acquired assets that used resources from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation. In the event that number resources of the receiving organization are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return, aggregate, transfer, or reclaim resources as needed to restore compliance via the processes outlined in current ARIN policy. Rationale: During policy discussions surrounding Draft Policy ARIN-2012-3 (ASN Transfers), the community was advised by ARIN Counsel that there are situations and cases currently making their way through the court system where an entity has gone bankrupt and a court is supervising liquidation of their assets. While number resources themselves are not assets, the exclusive right to those number resources is, and this addresses the need for these to be able to be moved with the other more tangible network assets. Timetable for implementation: immediate From owen at delong.com Wed May 9 17:20:13 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 9 May 2012 14:20:13 -0700 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy In-Reply-To: <4FAAD7B7.4050701@arin.net> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> Message-ID: <0D440324-3F7D-45C0-AFC8-8A67F6623483@delong.com> Opposed as written. While I like the idea of a policy enabling transfers specific to Bankruptcy, I think such a policy does need to allow for the number resources to be transferred separate from the underlying infrastructure in order to meet the real world requirements of such transactions. I would most probably support this policy if it were modified to make those accommodations, but, it would depend in part on guidance from ARIN counsel as to his ability to use the policy effectively. Owen (Speaking only for myself and not in my capacity as a member of the AC) On May 9, 2012, at 1:46 PM, ARIN wrote: > ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy > > 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-170 Transfer of Number Resources in case of Bankruptcy > > Proposal Originator: Christoph Blecker > > Proposal Version: 1.0 > > Date: 9 May 2012 > > Policy term: permanent > > Policy statement: > > NRPM 8.4 Bankruptcy Proceedings > Similar to section 8.2, ARIN will consider requests for the transfer of number resources in the case of bankruptcy or other court-supervised liquidation proceedings upon receipt of evidence that the receiving entity has acquired assets that used resources from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation. > > In the event that number resources of the receiving organization are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return, aggregate, transfer, or reclaim resources as needed to restore compliance via the processes outlined in current ARIN policy. > > Rationale: > > During policy discussions surrounding Draft Policy ARIN-2012-3 (ASN Transfers), the community was advised by ARIN Counsel that there are situations and cases currently making their way through the court system where an entity has gone bankrupt and a court is supervising liquidation of their assets. While number resources themselves are not assets, the exclusive right to those number resources is, and this addresses the need for these to be able to be moved with the other more tangible network assets. > > 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 jcurran at arin.net Wed May 9 20:13:25 2012 From: jcurran at arin.net (John Curran) Date: Thu, 10 May 2012 00:13:25 +0000 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 Apr 30, 2012, at 10:19 AM, 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 > I was asked recently about the number of issued and not presently advertised ASN's in the ARIN region, and thought it best to reply publicly so everyone has the same information. ARIN does not directly monitor ASN usage, but the esteemed Geoff Huston does at >From that report as of this morning - There are 24406 16-bit ASN's assigned to the ARIN region, with 1099 presently in the regional free pool, 8259 unadvertised in BGP, and 15048 advertised in BGP. FYI, /John John Curran President and CEO ARIN From bill at herrin.us Wed May 9 20:30:42 2012 From: bill at herrin.us (William Herrin) Date: Wed, 9 May 2012 20:30:42 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> Message-ID: On 5/9/12, John Curran wrote: >> ARIN-2012-3: ASN Transfers > > I was asked recently about the number of issued and not presently > advertised ASN's in the ARIN region, and thought it best to reply > publicly so everyone has the same information. > > ARIN does not directly monitor ASN usage, but the esteemed > Geoff Huston does at > > >From that report as of this morning - > > There are 24406 16-bit ASN's assigned to the ARIN region, with > 1099 presently in the regional free pool, 8259 unadvertised in > BGP, and 15048 advertised in BGP. Interesting! For folks looking for a reason for AS number transfers, here's a thought: Implementing BGP communities is a nuisance with a 32-bit AS number. The convention is: 16 bits AS number, 16 bits tag. Virtually every shipping router is configured to display them in this manner. AS numbers larger than 65535 require a service provider who wants to offer communities to implement it in an unconventional manner. This can be expected to cause collisions and other confusion in this tagging mechanism for downstreams with more than one BGP link. Where an organization wishes to implement communities, a 16-bit AS number is *highly* desirable on a technical basis. Geoff's numbers suggest that there are upwards of 8,000 16-bit as numbers recoverable in the ARIN region, some third of the total. Given some incentive for the current holders to release them of course. When we run out of fresh 16-bit AS numbers, the availability of those 8,000 would simplify operations for new ISPs and new ISP efforts which use a distinct AS number. Tom, is that a good enough reason to allow an AS number transfer? As a technical necessity to follow the conventions for BGP communities? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmaimon at chl.com Wed May 9 20:49:38 2012 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 09 May 2012 20:49:38 -0400 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy In-Reply-To: <0D440324-3F7D-45C0-AFC8-8A67F6623483@delong.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <0D440324-3F7D-45C0-AFC8-8A67F6623483@delong.com> Message-ID: <4FAB10A2.6010605@chl.com> Opposed to the concept. I dont believe it wise to create special policy that adds value to an "asset" only during bankruptcy procedure. M-A transfers when bankruptcy liquidates largely intact networks. Directed transfers when bankrupty liquidates number resources as a severable asset of value, with the source of that value contained solely as its status as a row inside the ARIN database, owned by ARIN, adminsistered according to the policies of its community. Sooner or later we will have to stand our ground and defend the concept that the number is not inherently property and the value contained in the resource is a collection of the community acquiescence to its uniqueness, and that you cannot legally compel that acquiescence. That you may sell whatever the parties involved agree to, but only what you actually own can be conveyed. Joe Owen DeLong wrote: > Opposed as written. > > While I like the idea of a policy enabling transfers specific to Bankruptcy, I think such a policy does need to allow for the number resources to be transferred separate from the underlying infrastructure in order to meet the real world requirements of such transactions. > > I would most probably support this policy if it were modified to make those accommodations, but, it would depend in part on guidance from ARIN counsel as to his ability to use the policy effectively. > > Owen > (Speaking only for myself and not in my capacity as a member of the AC) > > On May 9, 2012, at 1:46 PM, ARIN wrote: From owen at delong.com Wed May 9 21:01:07 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 9 May 2012 18:01:07 -0700 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> Message-ID: On May 9, 2012, at 5:30 PM, William Herrin wrote: > On 5/9/12, John Curran wrote: >>> ARIN-2012-3: ASN Transfers >> >> I was asked recently about the number of issued and not presently >> advertised ASN's in the ARIN region, and thought it best to reply >> publicly so everyone has the same information. >> >> ARIN does not directly monitor ASN usage, but the esteemed >> Geoff Huston does at >> >>> From that report as of this morning - >> >> There are 24406 16-bit ASN's assigned to the ARIN region, with >> 1099 presently in the regional free pool, 8259 unadvertised in >> BGP, and 15048 advertised in BGP. > > Interesting! > > For folks looking for a reason for AS number transfers, here's a thought: > > Implementing BGP communities is a nuisance with a 32-bit AS number. > The convention is: 16 bits AS number, 16 bits tag. Virtually every > shipping router is configured to display them in this manner. AS > numbers larger than 65535 require a service provider who wants to > offer communities to implement it in an unconventional manner. This > can be expected to cause collisions and other confusion in this > tagging mechanism for downstreams with more than one BGP link. Where > an organization wishes to implement communities, a 16-bit AS number is > *highly* desirable on a technical basis. > > Geoff's numbers suggest that there are upwards of 8,000 16-bit as > numbers recoverable in the ARIN region, some third of the total. Given > some incentive for the current holders to release them of course. When > we run out of fresh 16-bit AS numbers, the availability of those 8,000 > would simplify operations for new ISPs and new ISP efforts which use a > distinct AS number. > Actually, Geoff's numbers only suggest that there are ?8259 recoverable numbers. They provide no lower bound whatsoever on the number. The mere fact that a number does not appear in a routing table visible to Geoff Huston's research in no way indicates that it is not fully utilized in a context which is not visible to Geoff and which still requires global uniqueness. > Tom, is that a good enough reason to allow an AS number transfer? As a > technical necessity to follow the conventions for BGP communities? > I don't know about Tom, but, for me, no, it really isn't. We're going to have to face 32 bit ASNs with BGP communities sooner or later anyway. As such, some form of convention needs to be adopted and we might as well get on with it. Owen From jcurran at arin.net Wed May 9 21:16:20 2012 From: jcurran at arin.net (John Curran) Date: Thu, 10 May 2012 01:16:20 +0000 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> Message-ID: <7A8CCF51-401E-4FDC-81B1-F0064A1566DA@arin.net> On May 9, 2012, at 6:01 PM, Owen DeLong wrote: > > Actually, Geoff's numbers only suggest that there are ?8259 recoverable > numbers. They provide no lower bound whatsoever on the number. That is correct. > The mere fact that a number does not appear in a routing table visible > to Geoff Huston's research in no way indicates that it is not fully utilized > in a context which is not visible to Geoff and which still requires global > uniqueness. Agreed. While I have heard of a few AS numbers over the years being used in completely private routing situations, there is no clear method for determining that which is "not visible" by definition. FYI, /John John Curran President and CEO ARIN From christopher.morrow at gmail.com Wed May 9 22:45:05 2012 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 9 May 2012 22:45:05 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> Message-ID: i hate to jump in, but... On Wed, May 9, 2012 at 8:30 PM, William Herrin wrote: > On 5/9/12, John Curran wrote: >>> ?ARIN-2012-3: ASN Transfers >> >> I was asked recently about the number of issued and not presently >> advertised ASN's in the ARIN region, and thought it best to reply >> publicly so everyone has the same information. >> >> ARIN does not directly monitor ASN usage, but the esteemed >> Geoff Huston does at >> >> >From that report as of this morning - >> >> ? ?There are 24406 16-bit ASN's assigned to the ARIN region, with >> ? ?1099 presently in the regional free pool, 8259 unadvertised in >> ? ?BGP, and 15048 advertised in BGP. > > Interesting! > > For folks looking for a reason for AS number transfers, here's a thought: > > Implementing BGP communities is a nuisance with a 32-bit AS number. > The convention is: 16 bits AS number, 16 bits tag. Virtually every > shipping router is configured to display them in this manner. AS this sounds like an implementation issue with your vendor(s), not a technical reason for anything to change. vote with your $$ when talking to vendors. > tagging mechanism for downstreams with more than one BGP link. Where > an organization wishes to implement communities, a 16-bit AS number is > *highly* desirable on a technical basis. no, it really means that again vendors are leaving operations folk hanging :( more bug reports to vendors seem to be in order. > Geoff's numbers suggest that there are upwards of 8,000 16-bit as > numbers recoverable in the ARIN region, some third of the total. Given that is not at all what they suggest. the numbers geoff presents/records only show that 8k asn are not visible from his views of the global table. They may appear in someone (or many someones) else's tables though... or they may exist inside places not visible to the outside world. (btw, I support the proposal going forward to implementation) -chris From mysidia at gmail.com Wed May 9 23:49:21 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 9 May 2012 22:49:21 -0500 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> Message-ID: On 5/9/12, William Herrin wrote: > On 5/9/12, John Curran wrote: > For folks looking for a reason for AS number transfers, here's a thought: > > Implementing BGP communities is a nuisance with a 32-bit AS number. > The convention is: 16 bits AS number, 16 bits tag. Virtually every [snip] What you have shown is a good justification for obtaining a 16-bit AS number. It's actually a valid justification, unlike other poor excuses such as "a provider I want to peer with doesn't like 32bit numbers" There are other solutions besides AS transfers that do not encourage spammers to figure out which ASes are unused, and bulk mail WHOIS contacts with solicitations to sell their ASN. ARIN should assign 32-bit AS numbers to organizations that can use 32-bit AS numbers, reserve 16-bit AS numbers to organizations who have a clear technical issue such as use of such communities; which impacts their network implementation. 16bit numbers should be available to assign to orgs that have a reason such as that, and for ARIN to make sure they are available requires that some of the 16bit numbers not be available in the absence of a strong technical reason such as that. It is not apparent that enabling specified transfers is the most efficient way to reclaim AS numbers that are no longer in use, however. Since there are only at most 8000 of them, in theory, and these AS numbers are subject to RIR policy, there is not a massive swamp of "Legacy AS numbers", I would suggest an alternate method of reclaiming unused 16-bit AS numbers: ARIN can compile a list of AS numbers that have been assigned more than 90 days ago but do not appear as an Origin or Path member in globally visible BGP prefix listings. ARIN can e-mail each resource holder that has an AS number which does not appear, requesting that the resource holder account for and show their usage of the AS number resource or return it. The same should occur for a previously active AS number that disappears from the table for more than 90 days. Responses showing a current private use of the AS number are not reclaimable. Any returned AS numbers become part of the allocatable pool. AS numbers from which no adequate response is received with a sufficient number of attempts to contact the AS number resource holder, place the AS holder in a "Not in good standing" status, the WHOIS Records for the AS go to "Resource not verified", the matter must be resolved before allocating, or transferring any IP address resources for the Org in or Out. If the resource holder cannot be reached / does not respond to the resource review request within 12 months, and the AS number still does not appear in global tables, the AS assignment is revoked. -- -JH From bill at telnetcommunications.com Thu May 10 13:49:44 2012 From: bill at telnetcommunications.com (Bill Sandiford) Date: Thu, 10 May 2012 13:49:44 -0400 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy In-Reply-To: <4FAB10A2.6010605@chl.com> Message-ID: +1. Opposed I do not believe it is wise to have bifurcated policy for bankruptcy and non-bankruptcy situations. Regards, Bill On 12-05-09 8:49 PM, "Joe Maimon" wrote: >Opposed to the concept. > >I dont believe it wise to create special policy that adds value to an >"asset" only during bankruptcy procedure. > >M-A transfers when bankruptcy liquidates largely intact networks. > >Directed transfers when bankrupty liquidates number resources as a >severable asset of value, with the source of that value contained solely >as its status as a row inside the ARIN database, owned by ARIN, >adminsistered according to the policies of its community. > >Sooner or later we will have to stand our ground and defend the concept >that the number is not inherently property and the value contained in >the resource is a collection of the community acquiescence to its >uniqueness, and that you cannot legally compel that acquiescence. > >That you may sell whatever the parties involved agree to, but only what >you actually own can be conveyed. > >Joe > > >Owen DeLong wrote: >> Opposed as written. >> >> While I like the idea of a policy enabling transfers specific to >>Bankruptcy, I think such a policy does need to allow for the number >>resources to be transferred separate from the underlying infrastructure >>in order to meet the real world requirements of such transactions. >> >> I would most probably support this policy if it were modified to make >>those accommodations, but, it would depend in part on guidance from ARIN >>counsel as to his ability to use the policy effectively. >> >> Owen >> (Speaking only for myself and not in my capacity as a member of the AC) >> >> On May 9, 2012, at 1:46 PM, ARIN wrote: > > >_______________________________________________ >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 christoph.blecker at ubc.ca Thu May 10 16:40:20 2012 From: christoph.blecker at ubc.ca (Blecker, Christoph) Date: Thu, 10 May 2012 20:40:20 +0000 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy In-Reply-To: <4FAAD7B7.4050701@arin.net> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> Message-ID: <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> Just a few comments as the originator: My purpose for writing this (it's my first formal proposal, so please be kind!) was to solve one of the issues that ARIN Counsel spoke about at ARIN XXIX surrounding draft policy ARIN-2012-3. I actually share some of the concerns brought up by other community members on this list around assigning value to ASN numbers or other number resources. It's my own personal belief that allowing values to be placed on those resources isn't a good thing, and should be avoided where possible. The simplest way I saw to avoid assigning value or abusing this policy, was to tie the resources to other tangible assets that do have value. I actually agree it might not be the best, but I wanted to get the discussion going. The heart of the issue I'm trying to get at is solving a very real legal issue for ARIN Counsel, while not opening the door for artificial valuation of number resources (except for IPv4 addresses per what 8.3 already permits). I am very open to other community suggestions to modify this, or other ways to accomplish this goal. The result of this would be to have something in place to deal with bankruptcy situations, and not have that one piece cloud the ongoing discussion on ARIN-2012-3 (or other future talks about transfers of resources). Thank you to all for your input. Cheers, Christoph > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: May-09-12 1:47 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of > Bankruptcy > > ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy > > 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-170 Transfer of Number Resources in case of Bankruptcy > > Proposal Originator: Christoph Blecker > > Proposal Version: 1.0 > > Date: 9 May 2012 > > Policy term: permanent > > Policy statement: > > NRPM 8.4 Bankruptcy Proceedings > Similar to section 8.2, ARIN will consider requests for the transfer of > number resources in the case of bankruptcy or other court-supervised > liquidation proceedings upon receipt of evidence that the receiving > entity has acquired assets that used resources from the current > registrant. ARIN will maintain an up-to-date list of acceptable types of > documentation. > > In the event that number resources of the receiving organization are no > longer justified under ARIN policy at the time ARIN becomes aware of the > transaction, through a transfer request or otherwise, ARIN will work > with the resource holder(s) to return, aggregate, transfer, or reclaim > resources as needed to restore compliance via the processes outlined in > current ARIN policy. > > Rationale: > > During policy discussions surrounding Draft Policy ARIN-2012-3 (ASN > Transfers), the community was advised by ARIN Counsel that there are > situations and cases currently making their way through the court system > where an entity has gone bankrupt and a court is supervising liquidation > of their assets. While number resources themselves are not assets, the > exclusive right to those number resources is, and this addresses the > need for these to be able to be moved with the other more tangible > network assets. > > 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 scottleibrand at gmail.com Thu May 10 17:29:43 2012 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 10 May 2012 16:29:43 -0500 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy In-Reply-To: <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> Message-ID: On Thu, May 10, 2012 at 3:40 PM, Blecker, Christoph < christoph.blecker at ubc.ca> wrote: > Just a few comments as the originator: > My purpose for writing this (it's my first formal proposal, so please be > kind!) was to solve one of the issues that ARIN Counsel spoke about at ARIN > XXIX surrounding draft policy ARIN-2012-3. > > I actually share some of the concerns brought up by other community > members on this list around assigning value to ASN numbers or other number > resources. It's my own personal belief that allowing values to be placed on > those resources isn't a good thing, and should be avoided where possible. > > The simplest way I saw to avoid assigning value or abusing this policy, > was to tie the resources to other tangible assets that do have value. I > actually agree it might not be the best, but I wanted to get the discussion > going. The heart of the issue I'm trying to get at is solving a very real > legal issue for ARIN Counsel, while not opening the door for artificial > valuation of number resources (except for IPv4 addresses per what 8.3 > already permits). I am very open to other community suggestions to modify > this, or other ways to accomplish this goal. The result of this would be to > have something in place to deal with bankruptcy situations, and not have > that one piece cloud the ongoing discussion on ARIN-2012-3 (or other future > talks about transfers of resources). > > Thank you to all for your input. Christoph, First off, thanks for submitting a proposal on a timely issue, and solidifying the discussion around a core issue. As it currently reads, NRPM 8.2 allows for the transfer of any number resources (IPv4, IPv6, and ASNs) when the underlying network resources that justified the resources(s) are transferred through merger or acquisition activity (including bankruptcy). The challenge identified by Counsel, as I understand it, is that sometimes organizations (particularly those being broken up during bankruptcy) wish to transfer the right to use number resources separately from the underlying tangible assets in order to maximize their value. That is currently only allowed for IPv4 resources, via 8.3 transfers. If we think it only appropriate to allow ASN transfers when underlying network equipment is being transferred, then I don't think any new policy is necessary. However, if we think it would be appropriate to allow ASNs to be transferred independently of the underlying network resources in certain situations, that would require new policy, and the framework you've proposed (or a similar modification of 8.2) would be an excellent place to start. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Thu May 10 17:54:21 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 10 May 2012 17:54:21 -0400 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy In-Reply-To: References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> Message-ID: On Thu, May 10, 2012 at 5:29 PM, Scott Leibrand wrote: > On Thu, May 10, 2012 at 3:40 PM, Blecker, Christoph < > christoph.blecker at ubc.ca> wrote: > [ clip ] > > If we think it only appropriate to allow ASN transfers when underlying > network equipment is being transferred, then I don't think any new policy > is necessary. However, if we think it would be appropriate to allow ASNs > to be transferred independently of the underlying network resources in > certain situations, that would require new policy, and the framework you've > proposed (or a similar modification of 8.2) would be an excellent place to > start. > > There are two scenarios in order to maximize the value of an ASN in this context. Transfer with a functional network which "may" be later integrated into another ASN -- this makes the ASN more valuable if it can then be transferred for an additional value after its no longer needed. Transfer with the dead assets of a network. Bundled, the ASN has no value, it's part of a storage locker that gets picked apart for its value and has the rest discarded sometimes improperly. Compartmentalized, the ASN may have value depending on it's marketability (aesthetics, PI concepts, availability, etc.) and possibly how many bytes although in this context its assumed it's two-bytes only. It requires a framework that supports maximizing value in the interest of continued use of the resource. Letting debtors recover their capital in order to return a resource to use would be reasonable stewardship. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu May 10 18:29:36 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 10 May 2012 15:29:36 -0700 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy In-Reply-To: References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> Message-ID: <437EDA2C-2EA7-49E5-BF5C-3AD26917F9C9@delong.com> On May 10, 2012, at 2:54 PM, Martin Hannigan wrote: > > > On Thu, May 10, 2012 at 5:29 PM, Scott Leibrand wrote: > On Thu, May 10, 2012 at 3:40 PM, Blecker, Christoph wrote: > > > [ clip ] > > > If we think it only appropriate to allow ASN transfers when underlying network equipment is being transferred, then I don't think any new policy is necessary. However, if we think it would be appropriate to allow ASNs to be transferred independently of the underlying network resources in certain situations, that would require new policy, and the framework you've proposed (or a similar modification of 8.2) would be an excellent place to start. > > > > There are two scenarios in order to maximize the value of an ASN in this context. Transfer with a functional network which "may" be later integrated into another ASN -- this makes the ASN more valuable if it can then be transferred for an additional value after its no longer needed. Transfer with the dead assets of a network. Bundled, the ASN has no value, it's part of a storage locker that gets picked apart for its value and has the rest discarded sometimes improperly. Compartmentalized, the ASN may have value depending on it's marketability (aesthetics, PI concepts, availability, etc.) and possibly how many bytes although in this context its assumed it's two-bytes only. > > It requires a framework that supports maximizing value in the interest of continued use of the resource. Letting debtors recover their capital in order to return a resource to use would be reasonable stewardship. > Speaking very much strictly for myself and absolutely in no way wearing my AC hat: Maximizing the value of number resources is not a goal of ARIN policy. It is a goal of the bankruptcy courts. It is unfortunate, IMHO, that anyone perceives registrations of integers to actually have any intrinsic value, which is what we are actually talking about transferring here... Just the registrations of numbers, not the numbers themselves. Technically, not even any real legal right to use is being transferred. Sure, most cooperating ISPs on the internet recognize the RIR system as the registry of choice and conduct their routing accordingly, but, it is not actually illegal for an ISP to ignore the RIR system altogether and choose any other mechanism of address allocation they want. So long as they are able to peer with enough other organizations to get the data they want and deliver the data they care about delivering, there isn't really any issue with this. We use interesting terms like "prefix hijacking", "right to use", etc. to talk about this stuff, but, the reality is that these are all mostly fictitious except to the extent that they are implemented by cooperating bodies that voluntarily conform to the RIR structure. Admittedly, the community is reasonably good at shunning those who choose not to cooperate and that makes participation quasi-mandatory. To the best of my knowledge, nobody has yet been tested in court as to what happens if you successfully use numbers that ARIN registered to someone else on the internet in a manner that creates a significant conflict. As an example, were a large Redmond based convicted felon that develops software to suddenly decide they were going to use 192.124.41.0/24 as a prefix for delivering their next service, I suspect that the current registrant of that prefix would have little or no effective recourse other than depending on the voluntary cooperation of ISPs to disregard that particular route in favor of his use in accordance with ARIN policies. I'm quite certain that in spite of the registration situation at ARIN, the current resource holder would not have the necessary legal resources to successfully challenge the organization in question. The internet works because of the voluntary cooperation of the people who run routers working with the RIR system. If that breaks down, the internet will fracture and it will take considerable time for legislation to put it back together, if that is even possible. The good news is that almost everyone involved has a pretty strong vested interest in seeing the internet work and remain whole, so, non-cooperating entities can be treated as damage and routed around. This is why I regard the monetized transfer of IPv4 resources as a necessary but unfortunate reality of the exigent circumstances surrounding IPv4 runout. I wish we could count on IPv6 deployment to remove the need for these IPv4 transfers in the short term, but, reality is that we cannot. Indeed, we will, unfortunately, have to depend on the combination of problems these transfers will eventually create for IPv4 as the motivator to get the later hold-outs to move from IPv4 to IPv6. No such exigent circumstance exists with respect to ASNs. Unfortunately, this subtle nuance is probably very difficult to communicate to a court that is looking at a registration on one side and a willing purchaser on the other. To the court, the existence of a purchaser basically means that said registration must be an asset with a value. At this point, I think there are two ways we can go with that. We can acknowledge that value and make ARIN a little more of a free-for-all for the moneyed interests, or, we can decline to recognize such transfers, significantly reducing if not eliminating that value and depend on our able counsel to defend that position to the best of their ability even though they warned us it would be an uphill battle at best. I, personally, am inclined towards the latter in spite of my strong desire to give counsel every cooperation and tool that we can to help them defend ARIN and our policy process overall. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu May 10 18:44:15 2012 From: bill at herrin.us (William Herrin) Date: Thu, 10 May 2012 18:44:15 -0400 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy In-Reply-To: References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> Message-ID: On 5/10/12, Scott Leibrand wrote: > The challenge identified by Counsel, as I understand it, is that sometimes > organizations (particularly those being broken up during bankruptcy) wish > to transfer the right to use number resources separately from the > underlying tangible assets in order to maximize their value. That is > currently only allowed for IPv4 resources, via 8.3 transfers. I want reframe that a little bit to reflect my understanding of the issue. Please correct me if I have it wrong: "The lawful and correct way to transfer that asset requires the buyer to pre-qualify itself through a private organization, namely us" is a hard enough sell to a judge without adding "That asset is not severable from this group of assets over here. Furthermore, if that group of assets is broken up, this one must be abandoned despite willing buyers." Where the conditions of the bankruptcy and ARIN's policies collide in a way that requires ARIN counsel to make the second claim, ARIN places itself at unnecessary legal risk. A judge could very legitimately decide that an AS number is an asset and where the buyer would legitimately qualify for an AS number, he may legitimately acquire this one. Thereby overturning current ARIN policy. Worse, if a judge finds any piece of ARIN policy to be incompatible with bankruptcy law, the credibility of the rest is called in to question. Particularly in light of the brief from prospective buyer Address Sales R Us, claiming that ARIN restrictions on IP address transfer are unlawful restraint of trade. If ARIN were to simply "let it go" when someone wants to buy an AS number in bankruptcy, that whole dicey situation is avoided. Nobody has particularly cared about the AS number so far, but as transfers become more common and we run out of 16-bit AS numbers, the contemplated situation is likely to arise. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From astrodog at gmx.com Thu May 10 19:27:10 2012 From: astrodog at gmx.com (Astrodog) Date: Thu, 10 May 2012 18:27:10 -0500 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy In-Reply-To: References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> Message-ID: <4FAC4ECE.2090205@gmx.com> After reading through quite a few of the posts to the list on this topic, an alternate proposal comes to mind: Namely, that an organization that is being liquidated through bankruptcy no longer meets the needs-based requirements for an allocation or AS. What about simply revoking the resource when an entity enters liquidation, and perhaps give the purchasing entity a "fast track" way to be approved if they plan to continue to operate the network, with ARIN attempting to allocate the same number resource the old entity used to avoid renumbering pain where possible. Simply purchasing a pile of routers or other network infrastructure from a bankrupt entity does not in any way indicate that the purchaser meets the needs based requirements, before or after the sale. As it stands, this simply provides a way to work around the 8.3 requirements for a directed transfer. If the community consensus is that number resources are not an asset, revoking the allocation when an entity enters liquidation seems like the best way to handle these circumstances, as the entity being liquidated obviously no longer meets the needs based requirements, and the status of a purchaser is completely unknown. --- Harrison From owen at delong.com Thu May 10 19:52:40 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 10 May 2012 16:52:40 -0700 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy In-Reply-To: <4FAC4ECE.2090205@gmx.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> <4FAC4ECE.2090205@gmx.com> Message-ID: Personally, I like the idea, but, I'm not sure whether it would meet the legal requirements. Owen On May 10, 2012, at 4:27 PM, Astrodog wrote: > After reading through quite a few of the posts to the list on this > topic, an alternate proposal comes to mind: > > Namely, that an organization that is being liquidated through bankruptcy > no longer meets the needs-based requirements for an allocation or AS. > What about simply revoking the resource when an entity enters > liquidation, and perhaps give the purchasing entity a "fast track" way > to be approved if they plan to continue to operate the network, with > ARIN attempting to allocate the same number resource the old entity used > to avoid renumbering pain where possible. Simply purchasing a pile of > routers or other network infrastructure from a bankrupt entity does not > in any way indicate that the purchaser meets the needs based > requirements, before or after the sale. As it stands, this simply > provides a way to work around the 8.3 requirements for a directed transfer. > > If the community consensus is that number resources are not an asset, > revoking the allocation when an entity enters liquidation seems like the > best way to handle these circumstances, as the entity being liquidated > obviously no longer meets the needs based requirements, and the status > of a purchaser is completely unknown. > > --- Harrison > > > > > > _______________________________________________ > 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 drake.pallister at duraserver.com Thu May 10 19:58:07 2012 From: drake.pallister at duraserver.com (Drake Pallister) Date: Thu, 10 May 2012 19:58:07 -0400 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case Bankruptcy References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com><4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> Message-ID: <399E33D8E1934372AF089AE3501CB3CF@dp9100> To All, It's my belief that IP numbers should be treated in the same fashion as AS Numbers when conveying it/them to a different company. When speaking of this, we should make a distinction between Companies and Organizations as to not confuse some commercial (or even non-commercial such as a non-profit entity) operational entity with an ARIN "ORG" identification. So please let me say company or entity instead of organization unless I mean to refer to an ARIN "ORG" ID. With regard to bankruptcy, insolvency, foreclosure, or even a government seizure of an entity's "assets" we must guard the sovereignty of the ARIN-issued ASN's and IP allocations so they do not inadvertently become a bargaining chip--- so to speak, or a sellable, or bankable monetary asset of the company or entity that is in trouble. It is true that an ASN or an IP allocation facilitates a company / entity in providing services for its customers, subscribers, and even itself. However, the real assets of such a company is its customer base or network layout that allows them to do business. In the event of a non-profit entity such as some university, hospital, municipality, or even a worship entity, the real assets are again the services being provided or being had via Internet connectivity and routing. ASN's and IP allocations are Internet resources, parts of the actual Internet that a company or entity is granted usage of, to facilitate the transportation of their data, customers' and peers' data over the Internet At the risk of repeating myself, both (ASN's and IP allocations) ``in use by any such company or entity`` who has fallen in hot water financially or with the government to the extent where their real assets are subject to seizure, foreclosure, auction, or receivership should be pulled back by ARIN and held or safeguarded so they cannot become globed in, and construed as a tangible or sellable asset of the troubled entity along with their bank accounts, customer base, desks, pencils and paperclips. I've read much about the spirit of stewardship, and I believe that such as pull-back and safeguard of ASN's and IP allocations in those kinds of troubled situations, would be a prime example of stewardship, thus ruarding the resources and protecting the very Internet itself. As I have mentioned in another list posting, I'd surely recommend that ARIN examine the situation where ASN's or IP allocations are pulled back into their safe haven, and allow for the continued Internet routing and propagation of such "safe haven" ASN's or IP allocations to: 1.) not cause further devaluation to the endangered entity by disconnection of its subscriber base; 2.) assist in the non-disruption of IP services of the endangered company's end user customer, hence the general public; 3.) protect the physical integrity of such "safe haven"ASN's or IP allocations in the event the troubled entity successfully pulls itself out of its troubled condition; 4.) make administrative judgments of the ASN's or allocation's should the troubled company go to the point of liquidation. (2 and 3 being of a higher ethical importance) Comment: if the endangered entity becomes bought out by another, then regular transfer of resources procedures should apply. Rationale: During many instances where a company or entity is undergoing a potential meltdown, tear apart, investigation, foreclosure, etc., (which they might successfully recover from) their physical structure including their real assets often become shredded to piecemeal with bits and pieces falling under temporary or permanent control of unknown persons, entities, receivers, and impoundments--- potentially located in unforeseeable parts of the world. Even in situations where the troubled entity pulls through in good condition, many of their real assets and physical structure may have been devastated, squandered, and scattered, taking untold time to put back in place, with some not even recoverable. I as one person would want to prevent the sovereign structure of the Internet from becoming wrapped up, impounded, or otherwise globed in with such an entity's physical assets, subject to the happenings in the prior paragraph. Should the applicable company or entity ultimately fail to pull out of their trouble and go down the drain, break up or be liquidated then it would be at ARIN's discretion to reassign or reallocate the subject ASN's or IP allocations (to the entity(ies) who picked up the pieces of the liquidated company-- or not, depending on their administrative evaluation) I'm mostly referring to situations that may happen to members of the big-block fellows and not some micro-allocation, but if such a practice of a "safe haven" was utilized, there's no reason it couldn't be applied to a tiny micro-dot sized company's assignments or allocations. Conditions: In situations where ARIN would take back for guardianship or safe-keeping of the Internet components and allow the continued routing and propagation of said, this would not be expected of ARIN for free. Though I couldn't begin to construct a fee structure for all possible scenarios, I simply say that it should not be for free. For this kind of failsafe protection to work well, I'd believe that upon accepting any resources or annually paying for the resources, the holder may need to sign of on a simple stipulation that of the holder went into bankruptcy, foreclosure, insolvency, etc, that the resources would remand to an ARIN safe haven for the protection of said resources. Closing Comment: In my opinion, often worth a cup of cold coffee, this "stewardship" of the Internet's functional structure is not only the responsibility of ARIN and the other RIR's, but also extends to the entities having ASN's and IP allocations. However, the spirit of Internet stewardship will always be a hard sell to extend all the way to an individual end user even though he/she is a part of the Internet. I'd be glad to see my phrase "safe haven" or even "safe harbor" for Internet structural components be utilized. It's not actually the bankrupt company or the impounded entity being protected, it's the Internet resources themselves IP's and ASN's would be harbored in safety during a corporate battle or financial storm. Please take my opinions open mindedly as I have taken into consideration various outcomes for a failing or bankrupt entity holding pieces of the Internet's structure known as Resources. Is there anyone interested in creating a comprehensive proposal with me for a Resources Safe Haven/Harbor in special circumstances? With all respect, Drake Pallister ----- Original Message ----- From: "Blecker, Christoph" To: Sent: Thursday, May 10, 2012 4:40 PM Subject: Re: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy > Just a few comments as the originator: > My purpose for writing this (it's my first formal proposal, so please be > kind!) was to solve one of the issues that ARIN Counsel spoke about at > ARIN XXIX surrounding draft policy ARIN-2012-3. > > I actually share some of the concerns brought up by other community > members on this list around assigning value to ASN numbers or other number > resources. It's my own personal belief that allowing values to be placed > on those resources isn't a good thing, and should be avoided where > possible. > > The simplest way I saw to avoid assigning value or abusing this policy, > was to tie the resources to other tangible assets that do have value. I > actually agree it might not be the best, but I wanted to get the > discussion going. The heart of the issue I'm trying to get at is solving a > very real legal issue for ARIN Counsel, while not opening the door for > artificial valuation of number resources (except for IPv4 addresses per > what 8.3 already permits). I am very open to other community suggestions > to modify this, or other ways to accomplish this goal. The result of this > would be to have something in place to deal with bankruptcy situations, > and not have that one piece cloud the ongoing discussion on ARIN-2012-3 > (or other future talks about transfers of resources). > > Thank you to all for your input. > > Cheers, > Christoph > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of ARIN >> Sent: May-09-12 1:47 PM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case >> of >> Bankruptcy >> >> ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy >> >> 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-170 Transfer of Number Resources in case of Bankruptcy >> >> Proposal Originator: Christoph Blecker >> >> Proposal Version: 1.0 >> >> Date: 9 May 2012 >> >> Policy term: permanent >> >> Policy statement: >> >> NRPM 8.4 Bankruptcy Proceedings >> Similar to section 8.2, ARIN will consider requests for the transfer of >> number resources in the case of bankruptcy or other court-supervised >> liquidation proceedings upon receipt of evidence that the receiving >> entity has acquired assets that used resources from the current >> registrant. ARIN will maintain an up-to-date list of acceptable types of >> documentation. >> >> In the event that number resources of the receiving organization are no >> longer justified under ARIN policy at the time ARIN becomes aware of the >> transaction, through a transfer request or otherwise, ARIN will work >> with the resource holder(s) to return, aggregate, transfer, or reclaim >> resources as needed to restore compliance via the processes outlined in >> current ARIN policy. >> >> Rationale: >> >> During policy discussions surrounding Draft Policy ARIN-2012-3 (ASN >> Transfers), the community was advised by ARIN Counsel that there are >> situations and cases currently making their way through the court system >> where an entity has gone bankrupt and a court is supervising liquidation >> of their assets. While number resources themselves are not assets, the >> exclusive right to those number resources is, and this addresses the >> need for these to be able to be moved with the other more tangible >> network assets. >> >> 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. > _______________________________________________ > 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 astrodog at gmx.com Thu May 10 20:47:07 2012 From: astrodog at gmx.com (Astrodog) Date: Thu, 10 May 2012 19:47:07 -0500 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case Bankruptcy In-Reply-To: <399E33D8E1934372AF089AE3501CB3CF@dp9100> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com><4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> <399E33D8E1934372AF089AE3501CB3CF@dp9100> Message-ID: <4FAC618B.8080601@gmx.com> [snip] > > > Is there anyone interested in creating a comprehensive proposal with > me for a Resources Safe Haven/Harbor in special circumstances? > > With all respect, > Drake Pallister > +1, and I'd be happy to help. Such a "safe harbor" provision would also allow ARIN to allocate the resources to an entity that *does* continue the bankrupt entity's operations, which should help avoid the potential for re-numbering pain. I'd be very interested to hear John's thoughts on how this might work and if such a measure is economically feasible for ARIN. At the risk of repeating a discussion from a few months ago, the community consensus is clearly for needs-based allocation (I am not sure this is desirable, but that's an entirely different discussion). Since this is the case, all inter-party transfers should be subject to these provisions. Again, simply acquiring the routers and equipment of a bankrupt entity does not reflect on the IP and ASN allocation "needs" of the buyer. In the extreme, the network "equipment" behind some co-location providers has only nominal value, while the provider itself has a very large allocation due to the nature of their business. It should not be possible for me to obtain hundreds of thousands of IP addresses, without a needs test, simply by purchasing networking equipment with a market value equal to a low-mileage used car. As written, the policy would allow entities to use bankruptcy proceedings to ignore 8.3 transfer requirements. In the case of some entities, this may be significantly cheaper than an 8.3 transfer that they may not even qualify for. I don't see why a bankruptcy sale of networking equipment is somehow distinct in allocation terms from an entity selling the equipment without entering bankruptcy. ARIN does not allow automatic transfer of number resources in the latter case. If the purchasing entity intends to continue to operate the network of the bankrupt entity similarly to the way the bankrupt entity was, meeting the needs requirement should be trivial, and the safe harbor provision proposed above would ensure that such a transition could be performed relatively seamlessly as a standard 8.3 transfer. --- Harrison From paul at redbarn.org Thu May 10 21:26:32 2012 From: paul at redbarn.org (Paul Vixie) Date: Fri, 11 May 2012 01:26:32 +0000 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: <20120503T105531Z@localhost> 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> Message-ID: <4FAC6AC8.9060508@redbarn.org> On 2012-05-03 11:12 AM, Izaac wrote: > On Thu, May 03, 2012 at 01:08:08AM +0000, paul vixie wrote: >> ... we're not going to grow the internet economy another >> order of magnitude if we continue to reduce the accountability of the >> people and companies who can reserve unique resources. 'whois' or > ... If the bureaucratic energy were redirected into > IPv6 transition, we'd could begin to explore the kind of growth of which > you speak. as far as i know, we bureaucrats are doing all we can to facilitate and encourage that transition. if you have ideas on other things we can do, please send them along. > (Incidentally, do contact your local Austrian economist for a discussion > about whether central planning or a free market are more efficient at > allocating scarce resources.) the arin community's local austrian-school economist is dr. milton mueller, and he has indeed made the points you describe. unconvincingly from my point of view, but let's not forget about him altogether. paul From jcurran at arin.net Thu May 10 23:38:35 2012 From: jcurran at arin.net (John Curran) Date: Fri, 11 May 2012 03:38:35 +0000 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case Bankruptcy In-Reply-To: <4FAC618B.8080601@gmx.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> <399E33D8E1934372AF089AE3501CB3CF@dp9100> <4FAC618B.8080601@gmx.com> Message-ID: On May 10, 2012, at 5:47 PM, Astrodog wrote: > I don't see why a bankruptcy sale of networking equipment is somehow > distinct in allocation terms from an entity selling the equipment > without entering bankruptcy. ARIN does not allow automatic transfer of > number resources in the latter case. If the purchasing entity intends to > continue to operate the network of the bankrupt entity similarly to the > way the bankrupt entity was, meeting the needs requirement should be > trivial, and the safe harbor provision proposed above would ensure that > such a transition could be performed relatively seamlessly as a standard > 8.3 transfer. In the case of an entity acquiring the network operations of another firm and continuing to operate it in a similar manner, we already process these transfer requests in accordance with NRPM 8.2 (mergers and acquisitions). This applies equally well to networks which are sold as part of the normal bankruptcy process, and hence it is not exactly clear what additional benefits the "safe harbor" approach would provide over existing policy. FYI, /John John Curran President and CEO ARIN From narten at us.ibm.com Fri May 11 00:53:04 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 11 May 2012 00:53:04 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201205110453.q4B4r4Xf005856@rotala.raleigh.ibm.com> Total of 99 messages in the last 7 days. script run at: Fri May 11 00:53:04 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 27.27% | 27 | 22.75% | 202213 | bill at herrin.us 18.18% | 18 | 14.13% | 125555 | jcurran at arin.net 9.09% | 9 | 10.92% | 97028 | owen at delong.com 4.04% | 4 | 8.52% | 75732 | tvest at eyeconomics.com 2.02% | 2 | 6.27% | 55768 | jeffrey.lyon at blacklotus.net 3.03% | 3 | 4.69% | 41682 | scottleibrand at gmail.com 3.03% | 3 | 4.67% | 41529 | drake.pallister at duraserver.com 3.03% | 3 | 2.83% | 25147 | david at airbits.com 3.03% | 3 | 2.70% | 23993 | mysidia at gmail.com 2.02% | 2 | 1.92% | 17082 | lar at mwtcorp.net 2.02% | 2 | 1.86% | 16540 | farmer at umn.edu 2.02% | 2 | 1.48% | 13128 | astrodog at gmx.com 2.02% | 2 | 1.38% | 12273 | jmaimon at chl.com 2.02% | 2 | 1.34% | 11930 | info at arin.net 2.02% | 2 | 1.26% | 11222 | michael+ppml at burnttofu.net 1.01% | 1 | 1.74% | 15472 | kkargel at polartel.com 1.01% | 1 | 1.15% | 10192 | christoph.blecker at ubc.ca 1.01% | 1 | 1.11% | 9826 | hannigan at gmail.com 1.01% | 1 | 1.00% | 8923 | snowhorn at gmail.com 1.01% | 1 | 0.99% | 8795 | akara at tx-learn.net 1.01% | 1 | 0.90% | 7981 | narten at us.ibm.com 1.01% | 1 | 0.83% | 7406 | joelja at bogus.com 1.01% | 1 | 0.83% | 7389 | christopher.morrow at gmail.com 1.01% | 1 | 0.76% | 6727 | lea.roberts at stanford.edu 1.01% | 1 | 0.76% | 6723 | bill at telnetcommunications.com 1.01% | 1 | 0.69% | 6148 | john at egh.com 1.01% | 1 | 0.67% | 5913 | paul at redbarn.org 1.01% | 1 | 0.64% | 5706 | ppml at rs.seastrom.com 1.01% | 1 | 0.63% | 5623 | gary.buhrmaster at gmail.com 1.01% | 1 | 0.59% | 5224 | ppml at rsuc.gweep.net --------+------+--------+----------+------------------------ 100.00% | 99 |100.00% | 888870 | Total From astrodog at gmx.com Fri May 11 01:13:25 2012 From: astrodog at gmx.com (Astrodog) Date: Fri, 11 May 2012 00:13:25 -0500 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case Bankruptcy In-Reply-To: References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> <399E33D8E1934372AF089AE3501CB3CF@dp9100> <4FAC618B.8080601@gmx.com> Message-ID: <4FAC9FF5.9040909@gmx.com> On 5/10/2012 10:38 PM, John Curran wrote: > On May 10, 2012, at 5:47 PM, Astrodog wrote: > >> I don't see why a bankruptcy sale of networking equipment is somehow >> distinct in allocation terms from an entity selling the equipment >> without entering bankruptcy. ARIN does not allow automatic transfer of >> number resources in the latter case. If the purchasing entity intends to >> continue to operate the network of the bankrupt entity similarly to the >> way the bankrupt entity was, meeting the needs requirement should be >> trivial, and the safe harbor provision proposed above would ensure that >> such a transition could be performed relatively seamlessly as a standard >> 8.3 transfer. > In the case of an entity acquiring the network operations of another firm > and continuing to operate it in a similar manner, we already process these > transfer requests in accordance with NRPM 8.2 (mergers and acquisitions). > This applies equally well to networks which are sold as part of the normal > bankruptcy process, and hence it is not exactly clear what additional > benefits the "safe harbor" approach would provide over existing policy. > I believe one of the advantages of such an approach is to avoid the legal ambiguity the original policy proposal is designed to handle. By reverting the address space to ARIN upon entering liquidation/bankruptcy/etc, then reissuing the space to the purchaser, the property issue is much clearer, as ARIN is allocating the same block to the purchaser as a matter of convenience for all involved, as opposed to the original entity having the ability to initiate the transfer under liquidation. Part of the legal problem that 170 seems to be designed to handle originates in allowing the bankrupt entity to direct the transfer. A bankruptcy court can order various things *because* the originating entity has that ability. If losing control of the space was "automatic" if an entity ceases functioning, a bankruptcy court attempting to maximize value for an entity's debtors no longer has the ability to order a transfer, as the resources are no longer controlled by that entity, thus avoiding the potential for a bankruptcy court to order a transfer that would violate ARIN's policies. The existing policies also do not seem to explicitly state that a needs test is required to complete the transfer, ala 8.3, simply that if the resources are not justified, ARIN will work with the new owners to return/aggregate/transfer/reclaim the resources. No mechanism seems to exist for ARIN to actually test for this need to complete the transfer. Are you aware of any transfers under 8.2 that have been significantly altered after the fact due to failing the needs requirement? I'm curious as to how this process works, exactly, from the perspective of a purchaser. The existing guidelines for completing the transfer do not, as far as I can tell, explicitly require a needs test the way 8.3 transfers do. Do you have any thoughts as to what a policy like this entails, in terms of administrative and legal overhead, for ARIN? --- Harrison From jcurran at arin.net Fri May 11 07:04:56 2012 From: jcurran at arin.net (John Curran) Date: Fri, 11 May 2012 11:04:56 +0000 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case Bankruptcy In-Reply-To: <4FAC9FF5.9040909@gmx.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> <399E33D8E1934372AF089AE3501CB3CF@dp9100> <4FAC618B.8080601@gmx.com> <4FAC9FF5.9040909@gmx.com> Message-ID: <2CE9C3E7-BA75-4A65-A510-100E15C8A08A@arin.net> On May 10, 2012, at 10:13 PM, Astrodog wrote: > I believe one of the advantages of such an approach is to avoid the > legal ambiguity the original policy proposal is designed to handle. By > reverting the address space to ARIN upon entering > liquidation/bankruptcy/etc, then reissuing the space to the purchaser, > the property issue is much clearer, as ARIN is allocating the same block > to the purchaser as a matter of convenience for all involved, as opposed > to the original entity having the ability to initiate the transfer under > liquidation. > > Part of the legal problem that 170 seems to be designed to handle > originates in allowing the bankrupt entity to direct the transfer. A > bankruptcy court can order various things *because* the originating > entity has that ability. If losing control of the space was "automatic" > if an entity ceases functioning, a bankruptcy court attempting to > maximize value for an entity's debtors no longer has the ability to > order a transfer, as the resources are no longer controlled by that > entity, thus avoiding the potential for a bankruptcy court to order a > transfer that would violate ARIN's policies. It appears as through folks are working under very different assumptions with respect to ARIN and bankruptcy courts. To date, ARIN has been very successful in dealing with number resources in bankruptcy, and this is the result of having a very consistent legal framework which has been respected by the courts dealing with these matters. Specifically, ARIN asserts that parties do have certain rights to number resources registered to them, and this includes the right to unique use in the registry and the right to transfer in accordance with policy. There are other parties (such as the Internet community) which have rights to these same number resources (such as the right to public visibility to certain portions of the registration, the right to require certain contact information be present, etc.) It is the community-developed policy which determines the interaction of these rights. ARIN has dealt with bankruptcy courts before, and has prevailed to date in every case. To date, multiple IPv4 resources have been transferred in compliance with existing policy, and include the following proceedings and block sizes: In Nortel (Nortel I ? USA) (Delaware) 04/26/2011 9 /16?s; 1 /17; 1 /18; 4 /20?s; 2 /21?s; 1 /22; 4 /23?s; and 16 /24?s In re: Borders Group, Inc., et al., (S.D.NY) 12/20/2011 1 /16 In re: Teknowledge Corporation (N.D.CA) 1/24/2012 1 /16 In Northern Telecom Canada, Ltd. (Nortel II ? Canada) 2/24/2012 2/16?s In Bell-Northern Research (Nortel II ? Canada) 2/29/2012 1 /14, 2/29/2012 1 /14, 4/10/2012 2 /16?s In each of these matters, there is language noting ARIN's role in providing registration services, and in recent ones the language is generally to the effect that the recipient's interest in the number resources shall be subject to the terms and conditions agreed to by ARIN and recipient via registration services agreement, including applicable ARIN policies as published on our website. By having a consistent approach to these matters, one which acknowledges and respects certain rights that address holders have, we have been very successful and have never been ordered to update the registry contrary to community-developed policy. > Do you have any thoughts as to what a policy like this entails, in terms > of administrative and legal overhead, for ARIN? The proposed approach would be a significant departure from our existing efforts in this area, and would require some extensive legal assessment to determine the implications. I do not know offhand how it would affect ARIN's ability to provide registry services consistent with community policy, and/or whether it would improve or reduce our present success in this area. Thanks, /John John Curran President and CEO ARIN From astrodog at gmx.com Fri May 11 09:09:04 2012 From: astrodog at gmx.com (Astrodog) Date: Fri, 11 May 2012 08:09:04 -0500 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case Bankruptcy In-Reply-To: <2CE9C3E7-BA75-4A65-A510-100E15C8A08A@arin.net> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> <399E33D8E1934372AF089AE3501CB3CF@dp9100> <4FAC618B.8080601@gmx.com> <4FAC9FF5.9040909@gmx.com> <2CE9C3E7-BA75-4A65-A510-100E15C8A08A@arin.net> Message-ID: <4FAD0F70.2030504@gmx.com> [snip] > It appears as through folks are working under very different assumptions > with respect to ARIN and bankruptcy courts. To date, ARIN has been very > successful in dealing with number resources in bankruptcy, and this is the > result of having a very consistent legal framework which has been respected > by the courts dealing with these matters. Specifically, ARIN asserts that > parties do have certain rights to number resources registered to them, and > this includes the right to unique use in the registry and the right to > transfer in accordance with policy. There are other parties (such as the > Internet community) which have rights to these same number resources (such > as the right to public visibility to certain portions of the registration, > the right to require certain contact information be present, etc.) It is > the community-developed policy which determines the interaction of these > rights. > > ARIN has dealt with bankruptcy courts before, and has prevailed to date in > every case. To date, multiple IPv4 resources have been transferred in > compliance with existing policy, and include the following proceedings > and block sizes: > > In Nortel (Nortel I ? USA) (Delaware) 04/26/2011 9 /16?s; 1 /17; 1 /18; 4 /20?s; 2 /21?s; 1 /22; 4 /23?s; and 16 /24?s > In re: Borders Group, Inc., et al., (S.D.NY) 12/20/2011 1 /16 > In re: Teknowledge Corporation (N.D.CA) 1/24/2012 1 /16 > In Northern Telecom Canada, Ltd. (Nortel II ? Canada) 2/24/2012 2/16?s > In Bell-Northern Research (Nortel II ? Canada) 2/29/2012 1 /14, 2/29/2012 1 /14, 4/10/2012 2 /16?s > > In each of these matters, there is language noting ARIN's role in providing > registration services, and in recent ones the language is generally to the > effect that the recipient's interest in the number resources shall be subject > to the terms and conditions agreed to by ARIN and recipient via registration > services agreement, including applicable ARIN policies as published on our > website. > > By having a consistent approach to these matters, one which acknowledges > and respects certain rights that address holders have, we have been very > successful and have never been ordered to update the registry contrary to > community-developed policy. > I'm curious, in the case of the transfers outlined above, can you describe what needs testing was performed and if any of these transfers involved continuing to operate the acquired entity's network? This information makes me believe that we may have a solution searching for a problem, with both the original prop-170, and the "safe harbor" concept. --- Harrison From jcurran at arin.net Fri May 11 09:32:11 2012 From: jcurran at arin.net (John Curran) Date: Fri, 11 May 2012 13:32:11 +0000 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case Bankruptcy In-Reply-To: <4FAD0F70.2030504@gmx.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> <399E33D8E1934372AF089AE3501CB3CF@dp9100> <4FAC618B.8080601@gmx.com> <4FAC9FF5.9040909@gmx.com> <2CE9C3E7-BA75-4A65-A510-100E15C8A08A@arin.net>, <4FAD0F70.2030504@gmx.com> Message-ID: <137A888C-5057-4D37-A9C8-FB7D5BB30C4A@arin.net> On May 11, 2012, at 6:09 AM, "Astrodog" wrote: > I'm curious, in the case of the transfers outlined above, can you > describe what needs testing was performed and if any of these transfers > involved continuing to operate the acquired entity's network? All of these were under NRPM 8.3, and therefore the recipient had to demonstrate operational need sufficient for the resources before transfer. There is no requirement under NRPM 8.3 for the recipient to operate any of the assets, that is only a requiremet for validating M&A transfers (NRPM 8.2) > This information makes me believe that we may have a solution searching > for a problem, with both the original prop-170, and the "safe harbor" > concept. Indeterminate at this time, but that is possible. Thanks! /John John Curran President and CEO ARIN From kkargel at polartel.com Fri May 11 09:38:20 2012 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 11 May 2012 08:38:20 -0500 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy In-Reply-To: References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> <4FAC4ECE.2090205@gmx.com> Message-ID: <8695009A81378E48879980039EEDAD28012075D341@MAIL1.polartel.local> I like this idea also. It should be possible to revoke/suspend/quarantine the resources and place them in a holding pen for a time to allow the acquisitor (?) time to request/defend the acquisition. The problem I see is that the resource may need to stay in operation during the acquisition process to retain value. For example if a local cable company were to go in to bankruptcy and be acquired by one of their debtors who wanted to assume operation of the cable system, it would be harmful to have the number resources inoperable during the process. I would suggest a quarantine option, where the resources continued to be advertised without a listed operator, or with ARIN as the listed operator until transfer was effected or the q time expired and the resources were returned to the common pool. I would further suggest that this q time be unreasonably short (3 months?) with the facility for the court or acquisitor to request extension. The trick to all this is that it needs a trigger. I rather doubt that any operation is going to jump up and notify ARIN when they start a bankruptcy, rather they will start conversations with ARIN when numbers actually need attention. Bankruptcy courts are not going to preemptively notify ARIN of the start of proceedings without legislation requiring it. While it is a very good idea, I do not see how it would work in reality. Kevin > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Thursday, May 10, 2012 6:53 PM > To: Astrodog > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in > case of Bankruptcy > > Personally, I like the idea, but, I'm not sure whether it would meet the > legal requirements. > > Owen > > On May 10, 2012, at 4:27 PM, Astrodog wrote: > > > After reading through quite a few of the posts to the list on this > > topic, an alternate proposal comes to mind: > > > > Namely, that an organization that is being liquidated through bankruptcy > > no longer meets the needs-based requirements for an allocation or AS. > > What about simply revoking the resource when an entity enters > > liquidation, and perhaps give the purchasing entity a "fast track" way > > to be approved if they plan to continue to operate the network, with > > ARIN attempting to allocate the same number resource the old entity used > > to avoid renumbering pain where possible. Simply purchasing a pile of > > routers or other network infrastructure from a bankrupt entity does not > > in any way indicate that the purchaser meets the needs based > > requirements, before or after the sale. As it stands, this simply > > provides a way to work around the 8.3 requirements for a directed > transfer. > > > > If the community consensus is that number resources are not an asset, > > revoking the allocation when an entity enters liquidation seems like the > > best way to handle these circumstances, as the entity being liquidated > > obviously no longer meets the needs based requirements, and the status > > of a purchaser is completely unknown. > > > > --- Harrison > > > > > > > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4935 bytes Desc: not available URL: From hannigan at gmail.com Fri May 11 10:31:29 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 11 May 2012 10:31:29 -0400 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy In-Reply-To: <8695009A81378E48879980039EEDAD28012075D341@MAIL1.polartel.local> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> <4FAC4ECE.2090205@gmx.com> <8695009A81378E48879980039EEDAD28012075D341@MAIL1.polartel.local> Message-ID: On Fri, May 11, 2012 at 9:38 AM, Kevin Kargel wrote: > I like this idea also. It should be possible to revoke/suspend/quarantine > the resources and place them in a holding pen for a time to allow the > acquisitor (?) time to request/defend the acquisition. > > The problem I see is that the resource may need to stay in operation during > the acquisition process to retain value. For example if a local cable > company were to go in to bankruptcy and be acquired by one of their debtors > who wanted to assume operation of the cable system, it would be harmful to > have the number resources inoperable during the process. > > I'm not sure you can revoke what you do not control. Legacy ASN's are on the same bus as legacy IPv4 assets. We already know that revoking legacy v4 addresses is unlikely in at the very least the bankruptcy circumstance. Why would legacy ASN's be any different? I believe this thread has demonstrated that they do in fact have "value". Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri May 11 10:41:51 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 11 May 2012 07:41:51 -0700 Subject: [arin-ppml] 32-bit ASN Support References: <7048D5E6-0AFC-42EB-B091-9E4CBC26BE01@afrinic.net> Message-ID: <4D641B56-8D3E-4C21-9A85-C7C8FF36149E@delong.com> FYI -- AfriNIC is now issuing undifferentiated 32-bit AS Numbers. Owen Begin forwarded message: > From: Yogesh Chadee > Subject: [AfriNIC-rpd] AfriNIC Whois Database Changes - 4-byte ASN and DNSSEC support > Date: May 11, 2012 4:34:36 AM PDT > To: rpd at afrinic.net > > Dear colleagues, > > We are pleased to announce that AfriNIC now supports exclusively > 4-byte AS Numbers and shall not make any distinction between 2-byte > only AS Numbers (ASDOT) and 4-byte only AS Numbers (ASPLAIN). As from > now, AfriNIC will operate AS Number allocations from an > undifferentiated 4-byte AS Number allocation pool. This feature has > been implemented to be compliant with RFC5396 which deals with the > Textual Representation of Autonomous System (AS) Numbers. > > More information can be obtained from: > http://www.afrinic.net/docs/policies/AFPUB-2005-ASN-001.htm > http://tools.ietf.org/html/rfc5396 > > Moreover, AfriNIC will soon activate DNSSEC support on its DNS > infrastructure including the IANA delegated reverse zones we manage. > We have therefore implemented the "ds-rdata" attribute in the DOMAIN > object of the Whois database. This will allow members to publish > Delegation Signer (DS) records to build the chain of trust for their > RDNS zones. > > More information can be obtained from: > http://www.afrinic.net/dnssec > > Kind regards, > > ------------------------- > Yogesh Chadee > Software Engineer > AfriNIC > _______________________________________________ > rpd mailing list > rpd at afrinic.net > https://lists.afrinic.net/mailman/listinfo.cgi/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From drake.pallister at duraserver.com Fri May 11 12:04:40 2012 From: drake.pallister at duraserver.com (Drake Pallister) Date: Fri, 11 May 2012 12:04:40 -0400 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case Bankruptcy References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com><4FAAD7B7.4050701@arin.net><5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca><399E33D8E1934372AF089AE3501CB3CF@dp9100> <4FAC618B.8080601@gmx.com> Message-ID: <94ECE02B3FC246E585C1F6C40D0A5C40@DELLLAT> Dear Sirs: Thank you for your time and knowledge. I had originally posted a potential suggestion as an extra method of keeping safe, the ARIN resources of a failing company or entity during its disposition, reorganization or liquidation in such a way to blatantly segregate and keep separate, the "resources" so they don't become globed in with a failing company's real assets-- or become distorted as real assets in the minds of any unknowing, devious, or unintentionally negligent persons overseeing such a company's disassembly or reconstruction. My suggestion was not based upon a company being acquired and kept operating in the same manner. It had been a reply geared toward a situation where there was nothing like an orderly sale or merger, but a failing company being shreaded, torn down and with the Internet resources being considered as a sellable asset of the company. I had somewhere compared my suggestion to a safe haven or safe harbor (for the resources, of course). Please forgive me if that phrase is formally utilized somewhere within AIRN or NRPM specs. I believed that if the resources are temporarily taken back and secluded, it would place an additional layer of distance between the "resources" and the confusing troubles of the failing company comingling its assets and the resources. My suggestion of the safe harbor or safe haven was not to assist the failing company, nor facilitate a transfer to a potential purchaser(s). I was in fact attempting to come up with a suggestion to prevent Internet "resources" (ASN's , allocations) from being globed in with all of the failing company's sellable assets. Though we know that any new entity(ies) picking up the pieces from a failed company who is a resource holder must themselves qualify for issuance of the resources. The entity(ies) licking up the pieces shouldn't simply get an automatic ``walk`` or shoe-in because they picked up the pieces of a failed resource holder who had qualified. The safe harbor/haven protective custody idea is to prevent all of the uninformed, unknowledgeable people (bankers, lien holders, receivers, trustees) from believing or construing that these ARIN resources are 'not' any part of the failed/bankrupt company's sellable or impoundable real assets such as their bank accounts, equipment, desks, chairs, etc. Also, if any company is a state of insolvency or seizure, since I believe they are already therefore disqualified from being resource holders. That safe-holding in the case of a bankruptcy type of scenario would be a place within ARIN where such resources might be held in safety to: A.) remove the possible need for ARIN to have to struggle to regain the assets. B.) make for some method for the resources to stay active on the Internet, and not `throw into the dark` the failing company's customer base; also adding to a possibly further devaluation of the troubled company's remaining value, as their customer base would be impacted very negatively (innocent people of the general public) and would permanently disappear. C.) protect the resources ASN's, IP Allocations, whatever, intact in the event the troubled company successfully pulls through; or have those assets intact and readily available and under ARIN's roof for assignment to the entity(ies) picking up the pieces of the failed company if they don't pull through-- (provided they qualify, of course). During bankruptcy proceedings, foreclosures, or impoundments, real and perceived assets could be scattered, lost, traded, etc., and wind up in the hands of untold numbers of people or entities anywhere in the world. Even if the troubled company came back to health, some assets are likely to have been damaged or lost beyond recovery. ARIN should not be expected to do this for free. The safe haven/harbor idea is to provide a sovereign holding method for the Internet resources. If it happens to benefit the troubled company who does get back to health-- or the entity(ies) picking up the pieces if a liquidation is ultimately performed-- then so be it, as a side effect. However, during such a rough, devious, and confusing ride, the resources would remain protected and with absolute certainty that they are not globed in with the troubled company's real assets. The idea was to provide protection for the resources which are integral components of the Internet that we all watch over. With all respect, Drake Pallister ----- Original Message ----- From: "John Curran" To: "Astrodog" Cc: Sent: Thursday, May 10, 2012 11:38 PM Subject: Re: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case Bankruptcy > On May 10, 2012, at 5:47 PM, Astrodog wrote: > >> I don't see why a bankruptcy sale of networking equipment is somehow >> distinct in allocation terms from an entity selling the equipment >> without entering bankruptcy. ARIN does not allow automatic transfer of >> number resources in the latter case. If the purchasing entity intends to >> continue to operate the network of the bankrupt entity similarly to the >> way the bankrupt entity was, meeting the needs requirement should be >> trivial, and the safe harbor provision proposed above would ensure that >> such a transition could be performed relatively seamlessly as a standard >> 8.3 transfer. > > In the case of an entity acquiring the network operations of another firm > and continuing to operate it in a similar manner, we already process these > transfer requests in accordance with NRPM 8.2 (mergers and acquisitions). > This applies equally well to networks which are sold as part of the normal > bankruptcy process, and hence it is not exactly clear what additional > benefits the "safe harbor" approach would provide over existing policy. > > FYI, > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From izaac at setec.org Fri May 11 13:04:00 2012 From: izaac at setec.org (Izaac) Date: Fri, 11 May 2012 13:04:00 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <4FAC6AC8.9060508@redbarn.org> 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> Message-ID: <20120511T161218Z@localhost> On Fri, May 11, 2012 at 01:26:32AM +0000, Paul Vixie wrote: > as far as i know, we bureaucrats are doing all we can to facilitate and > encourage that transition. if you have ideas on other things we can do, > please send them along. Some ideas which you may actually consider? Off the top of my head, with little rationale exploration due to time constraint -- and hunger: - Outright REQUIRE IPv6 requests to correspond with and accompany all IPv4 requests. And then actually assign and issue that IPv6 space -- whether or not the requester has any intention of immediately using it. - Actively promote the establishment and maintenance of 6to4 gateways by all present IPv4 allocation holders above a sensibly arbitrary size, e.g. /20. And consider requiring them for new issues of that size. Further, provide incentive and reward for 6to4 anycast participation. - Actually bother to pronounce an IPv4 deprecation date. Only some weak detail as to what "deprecation" means would be necessary. And an 29OCT2019 date is so far off that it provides nothing more than some structure for planning. > > (Incidentally, do contact your local Austrian economist for a discussion > > about whether central planning or a free market are more efficient at > > allocating scarce resources.) > > the arin community's local austrian-school economist is dr. milton > mueller, and he has indeed made the points you describe. unconvincingly > from my point of view, but let's not forget about him altogether. Indeed. I'd revisit his suggestions. A market, when left to its devices, solves these problems with remarkable speed and little difficulty. It does so by leveraging all the knowledge, experience, requirements, and resources of its participants in a way that no series of conjectures, assertions, plans, and surveys are able. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From bill at herrin.us Fri May 11 13:31:29 2012 From: bill at herrin.us (William Herrin) Date: Fri, 11 May 2012 13:31:29 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <20120511T161218Z@localhost> 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> Message-ID: On 5/11/12, Izaac wrote: > On Fri, May 11, 2012 at 01:26:32AM +0000, Paul Vixie wrote: >> as far as i know, we bureaucrats are doing all we can to facilitate and >> encourage that transition. if you have ideas on other things we can do, >> please send them along. > > Some ideas which you may actually consider? Off the top of my head, > with little rationale exploration due to time constraint -- and hunger: > > - Outright REQUIRE IPv6 requests to correspond with and accompany all > IPv4 requests. And then actually assign and issue that IPv6 space -- > whether or not the requester has any intention of immediately using > it. Hi Izaac, Why make it even that difficult? Just preemptively assign an IPv6 address block to every registrant holding IPv4 addresses who does not already hold IPv6 addresses. Why wait until they ask? It isn't as if there's a shortage. As I recall there were three main reasons why not: 1. Although we insist folks need to deploy IPv6, we couldn't possibly assign them addresses until they publicly state the truth of our belief by making a paid application. 2. The preemptive block might possibly not be the right size, leading to a request for a second block and an entire extra route in the IPv6 BGP table. Never mind that it turns out somewhere between many and most of the initial IPv6 allocations have ended up being the wrong size anyway. As if the possibility that wouldn't happen had every been more than wishful thinking. 3. Per the IETF, all IPv6 end users are supposed to get IPs from their ISP, even though the technical basis for that plan has been thoroughly discredited for more or less every situation in which a registrant qualifies to hold ARIN IPv4 addresses. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mike at nationwideinc.com Fri May 11 14:06:49 2012 From: mike at nationwideinc.com (Mike Burns) Date: Fri, 11 May 2012 14:06:49 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29assignment identification requirement) In-Reply-To: <20120511T161218Z@localhost> 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 ><68767A02-BBC6-43D2-B62F-947829343038@arin.net><4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost><4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> Message-ID: <2E61984647A643FFBA39CA7BAAB0ABE5@MPC> +1 There is a lot of thrashing about to solve problems most naturally solved by a market. > > the arin community's local austrian-school economist is dr. milton > mueller, and he has indeed made the points you describe. unconvincingly > from my point of view, but let's not forget about him altogether. Indeed. I'd revisit his suggestions. A market, when left to its devices, solves these problems with remarkable speed and little difficulty. It does so by leveraging all the knowledge, experience, requirements, and resources of its participants in a way that no series of conjectures, assertions, plans, and surveys are able. From springer at inlandnet.com Fri May 11 14:45:41 2012 From: springer at inlandnet.com (John Springer) Date: Fri, 11 May 2012 11:45:41 -0700 (PDT) Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29assignment identification requirement) In-Reply-To: <2E61984647A643FFBA39CA7BAAB0ABE5@MPC> 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 ><68767A02-BBC6-43D2-B62F-947829343038@arin.net><4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost><4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <2E61984647A643FFBA39CA7BAAB0ABE5@MPC> Message-ID: <20120511113902.C4790@mail.inlandnet.com> -1 There is a lot of asserting of conjectures not proven, opposed by the unconvinced. On Fri, 11 May 2012, Mike Burns wrote: > +1 > There is a lot of thrashing about to solve problems most naturally solved by > a market. > > >> >> the arin community's local austrian-school economist is dr. milton >> mueller, and he has indeed made the points you describe. unconvincingly >> from my point of view, but let's not forget about him altogether. > > Indeed. I'd revisit his suggestions. A market, when left to its > devices, solves these problems with remarkable speed and little > difficulty. It does so by leveraging all the knowledge, experience, > requirements, and resources of its participants in a way that no series > of conjectures, assertions, plans, and surveys are able. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > From owen at delong.com Fri May 11 16:25:57 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 11 May 2012 13:25:57 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29assignment identification requirement) In-Reply-To: <2E61984647A643FFBA39CA7BAAB0ABE5@MPC> 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 ><68767A02-BBC6-43D2-B62F-947829343038@arin.net><4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost><4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <2E61984647A643FFBA39CA7BAAB0ABE5@MPC> Message-ID: <83A366BF-22FF-45F4-B409-07ABE3017CB8@delong.com> On May 11, 2012, at 11:06 AM, Mike Burns wrote: > +1 > There is a lot of thrashing about to solve problems most naturally solved by a market. -1 That depends on your definition of solved. In my experience, markets often (always?) create many problems along the way to that so-called solution. Markets are very efficient by the economists definition of efficiency, but, that is a very specific definition of efficient which doesn't necessarily parallel what everyone might expect nor does it necessarily indicate that the market optimizes for the parameters that most concern the community. Instead, the market tends to optimize for equilibrium between those with the ability to pay and those with resources desired by those with the ability to pay. For those whose ability to pay is below the threshold of that equilibrium, they are left out in the cold with no recourse. Should someone or a group of someones with an extreme ability to pay desire to reduce the size of the market, they have the ability to do so in order to better manipulate said market to suit their motives, at least for near-to-medium terms. So while markets do, indeed, naturally offer a set of solutions to some of the problems being described... The solution they offer is often contrary to the good of the community the market should be serving. >> the arin community's local austrian-school economist is dr. milton >> mueller, and he has indeed made the points you describe. unconvincingly >> from my point of view, but let's not forget about him altogether. > > Indeed. I'd revisit his suggestions. A market, when left to its > devices, solves these problems with remarkable speed and little > difficulty. It does so by leveraging all the knowledge, experience, > requirements, and resources of its participants in a way that no series > of conjectures, assertions, plans, and surveys are able. That's a nice pipe dream. However, what it leaves out is the fact that a market is driven by the participants with means to the conclusions and solutions that best suit those with the most means. In an environment where profit is the primary motivation for the existence of the market, that may even bey somewhat optimal. In an environment where the desired solution is more egalitarian, markets are incapable of producing an ideal solution and will often trend quite far away from a solution in favor of a profit. Owen From mysidia at gmail.com Fri May 11 23:58:58 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 11 May 2012 22:58:58 -0500 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy In-Reply-To: <8695009A81378E48879980039EEDAD28012075D341@MAIL1.polartel.local> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> <4FAC4ECE.2090205@gmx.com> <8695009A81378E48879980039EEDAD28012075D341@MAIL1.polartel.local> Message-ID: On 5/11/12, Kevin Kargel wrote: [snip] > The problem I see is that the resource may need to stay in operation during > the acquisition process to retain value. For example if a local cable [snip] Not only will the AS most likely need to stay in operation during an acquisition process, but ARIN must provide the accurate WHOIS data for the AS as long as it is in operation, so that the appropriate contacts can be properly reached if there are any issues related to the AS. Temporarily "delisting an AS" or any number resource still in operation is really just not proper. -- -JH From paul at redbarn.org Sat May 12 00:23:18 2012 From: paul at redbarn.org (paul vixie) Date: Sat, 12 May 2012 04:23:18 +0000 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: <2E61984647A643FFBA39CA7BAAB0ABE5@MPC> 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 ><68767A02-BBC6-43D2-B62F-947829343038@arin.net><4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost><4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <2E61984647A643FFBA39CA7BAAB0ABE5@MPC> Message-ID: <4FADE5B6.7060100@redbarn.org> On 5/11/2012 6:06 PM, Mike Burns wrote: > +1 > There is a lot of thrashing about to solve problems most naturally > solved by a market. mike, i heard the ceo of general foods quoted on the radio a while back, saying "we feed a billion people every day". as i consider various approaches, i don't think anything other than market capitalism would bring enough efficiency and motivation into the equation to do a job like that one. let the record show that i am a died in the wool capitalist and that i can quote ayn rand more accurately and more relevantly than any tea partier or libertarian. this discussion is not about markets. we're talking about stewardship of a scarce and artificial resource that's fundamental to the world's global commerce system and also to human society's nervous system. to the extent that a market can help, NRPM 8.3 opens a responsible way to do that, by requiring that recipients of transferred resource show a more or less immediate need for that resource, as called for in RFC 2050, which was the last revision of guidance by the community who created this artificial resource. in an unstewarded market, recipients could be speculators, hoarders, price manipulators, or worse. examples of this kind of market include the california electric power deregulation experiment of about ten years ago in which hoarding speculating price manipulators like enron made tons of money but the resource (electric power) was more expensive and less available than before the market was opened. i'm not insisting that that is inevitable in an unstewarded internet resource market, but i can tell you that the 'thrashing about' that you see here on PPML and at ARIN's Public Policy Meetings is working very well in my opinion: we have a stable investment climate for IP network builders because they know what the supply is, what the rules are, and how the rules can change. moving up-thread to a response i had not initially seen: >> [vixie] the arin community's local austrian-school economist is dr. >> milton >> mueller, and he has indeed made the points you describe. unconvincingly >> from my point of view, but let's not forget about him altogether. > > Indeed. I'd revisit his suggestions. A market, when left to its > devices, solves these problems with remarkable speed and little > difficulty. It does so by leveraging all the knowledge, experience, > requirements, and resources of its participants in a way that no > series of conjectures, assertions, plans, and surveys are able. see above. paul -- "I suspect I'm not known as a font of optimism." (VJS, 2012) From mysidia at gmail.com Sat May 12 03:58:45 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 12 May 2012 02:58:45 -0500 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <20120511T161218Z@localhost> 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> Message-ID: On 5/11/12, Izaac wrote: [snip] > - Outright REQUIRE IPv6 requests to correspond with and accompany all > IPv4 requests. And then actually assign and issue that IPv6 space -- 1. Problem... it encourages providers and end users to apply for IPv6 resources that they won't use. 2. The concept requires that IPv6 resources come from ARIN, but there may be other sources of v6 addresses such as an upstream, or a global organization has an IPv6 allocation from a different RIR; they should not be required to obtain their IPv6 space from ARIN. Maybe instead you want to add a requirement that IPv4 allocations for new networks be in compliance with RFC 6540, and the applicant to receive v4 by new allocation or by transfer show this, if they are not also applying for v6 address space.. > - Actively promote the establishment and maintenance of 6to4 gateways by > all present IPv4 allocation holders above a sensibly arbitrary size, 6to4 gateways are not necessarily an advisable migration strategy. 4to4 / CGN has significant advantages. > - Actually bother to pronounce an IPv4 deprecation date. Only some weak It would be inappropriate at this time for ARIN to announce a deprecation date for IPv4 or IPv4 addressing. It's not a RIR's place to do that; it's IETF's. If ARIN were to decide they wanted to get out of IPv4 addressing prematurely, it would be time at that point for them to be replaced as RIR for IPv4. > Indeed. I'd revisit his suggestions. A market, when left to its > devices, solves these problems with remarkable speed and little [snip] It's amazing that despite the enormous amount of evidence to the contrary, people keep regurgitating the totally unfounded myth that markets provide the good solution to all problems. If this were true, TCP/IP would not be deployed very much, because it would never have caught on; the market would have recognized this problem, and prevented TCP/IP from succeeding. Instead most networks would be using the best closed proprietary (and therefore most lucrative) replacement for TCP/IP that the market had brought us, which would have no IP address resource exhaustion problem from the beginning. -- -JH From paul at redbarn.org Sat May 12 12:03:21 2012 From: paul at redbarn.org (paul vixie) Date: Sat, 12 May 2012 16:03:21 +0000 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: <5DE8E4560B2B40DAA5F46A11DD03922D@video> 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><68767A02-BBC6-43D2-B62F-947829343038 @arin.net><4FA1DA78.4090401@redbarn.org><20120503T105531Z@localhost><4FAC6A C8.9060508@redbarn.org><20120511T161218Z@localhost> <2E61984647A643FFBA39CA7BAAB0ABE5@MPC> <4FADE5B6.7060100@redbarn.org> <5DE8E4560B2B40DAA5F46A11DD03922D@video> Message-ID: <4FAE89C9.5000700@redbarn.org> On 5/12/2012 1:30 PM, Mike Burns wrote: > No offense, Paul, but this discussion IS about market and stewardship. no offense taken, mike. > And forgive me if I doubt your level of libertarianism, any > libertarian I know would have simply pointed out that Enron went > bankrupt, taking many investors and management down. Hardly a shining > example of the faults of a market, and there is no doubt that the > market Enron operated in was far from free and open. i think we'd be far afield if we get into those details. my point in mentioning libertarianism was that i'm a knowledgeable amateur when it comes to the austrian school, but am not a knee-jerk anarcho-lib as some in this audience occasionally seem (to me). so i forgive you noting that we're at cross purposes here. > Instead of treating ASNs as the valuable and scarce resources they > are, and creating policies to engender their recycling and re-use > through the profit motive, they languish like IPv4 addresses did > before we began to create a market for them. on the merits of the specific policy you mention (asn reassignment), i've heard no credible benefit to it and one credible cost. i call "4-byte asn's are less desireable" a canard, because many operators around the world use them successfully and these asn's represent the inevitable future once the 2-byte pool is exhausted. if i thought we could have "steady state forever" on 2-byte then i'd think differently. there is a cost in recycling, brought up in the vancouver meeting by bill woodcock, which is that old network traces stored on disk are pretty stable in the asn:identity mapping. some asn's have churned, like 174 used to be psi and is now cogent. most have not churned. someone sitting on a 20-year pile of netflow or bgp traces may not thank us for making them go back and put a time-domain on every asn reference. that's a small matter but it's more credible than the best example yet given as to why asn's should be recycled more freely. (yes, i wish i had asn 42 instead of woody... because of douglas adams. that doesn't make it good policy.) > You will note that my policy prescriptions always separate the free > pool from the pool of already allocated resources. I have no problem > with a needs test and other central control of the free pool, but > markets work best for allocations of resources already held by > disparate parties. you could argue that the goodness of stewardship depends on the efficiency of utilization, and that an asn sitting on the beach unable to be recycled is therefore a bad thing. i don't think anyone could argue. if you do this, you should quote arin's mission statement and the relevant parts of rfc 2050. but if you argue on the basis that markets are good, i predict very little traction. -- "I suspect I'm not known as a font of optimism." (VJS, 2012) From owen at delong.com Sat May 12 12:06:34 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 12 May 2012 09:06:34 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> Message-ID: >> - Actively promote the establishment and maintenance of 6to4 gateways by >> all present IPv4 allocation holders above a sensibly arbitrary size, > > 6to4 gateways are not necessarily an advisable migration strategy. > 4to4 / CGN has significant advantages. > 6to4 gateways aren't so much a migration strategy as a way to connect IPv6 islands across an IPv4 ocean. 4to4/CGN offer an alleged solution to a completely different problem -- How to multiplex more IPv4 connections onto a single IPv4 address. (Also not a migration strategy, but instead a strategy for attempting to avoid migration.) Frankly, anyone who has looked at the details of CGN and truly considered the problems of CGN would prefer to do native IPv6 with CGN providing only the minimal amount of connectivity to unfortunate IPv4 only end-points and would be actively seeking to encourage popular IPv4 only end-points to add IPv6 capabilities as quickly as possible. The alternatives which could be called a migration strategy are NAT64/DNS64 which provides a mechanism for an IPv6-only host to make an IPv6 connection to a proxy host which "NATs" that connection (it's really more like a proxy) to an IPv4 connection to the true destination and DS-LITE which tunnels IPv4 private addresses over the providers IPv6 network to a CGN NAT44 box. All of these so-called solutions have tradeoffs and the only one which does not provide a degraded user experience is dual-stacked content providers during the transition period with the eventual goal of native IPv6 everywhere. > >> - Actually bother to pronounce an IPv4 deprecation date. Only some weak > > It would be inappropriate at this time for ARIN to announce a > deprecation date for > IPv4 or IPv4 addressing. It's not a RIR's place to do that; > it's IETF's. > Good luck getting the IETF to come to consensus on that one. > If ARIN were to decide they wanted to get out of IPv4 addressing prematurely, > it would be time at that point for them to be replaced as RIR for IPv4. > Agreed. > >> Indeed. I'd revisit his suggestions. A market, when left to its >> devices, solves these problems with remarkable speed and little > [snip] > > It's amazing that despite the enormous amount of evidence to the contrary, > people keep regurgitating the totally unfounded myth that markets > provide the good > solution to all problems. > +1 > If this were true, TCP/IP would not be deployed very much, > because it would > never have caught on; the market would have recognized this problem, > and prevented > TCP/IP from succeeding. Instead most networks would be using the > best closed proprietary (and therefore most lucrative) replacement for > TCP/IP that the market had brought us, which would have no IP > address resource exhaustion problem from the beginning. Here, I think you drive off the rails a bit. Open Source can be the most efficient and most lucrative solution to a problem and a market can and has recognized that efficiency many times (Linux, Apache, SSH). Just because markets are often wrong (X11, Motif, Windows, Enron, Tulips, Housing) does not mean that they always are. Owen From izaac at setec.org Sat May 12 21:58:47 2012 From: izaac at setec.org (Izaac) Date: Sat, 12 May 2012 21:58:47 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> Message-ID: <20120513T004128Z@localhost> On Sat, May 12, 2012 at 02:58:45AM -0500, Jimmy Hess wrote: > > - Outright REQUIRE IPv6 requests to correspond with and accompany all > > IPv4 requests. And then actually assign and issue that IPv6 space -- > > 1. Problem... it encourages providers and end users to apply for > IPv6 resources that they won't use. It compels requesters to consider deployment at least as far as completing the paperwork. They may go ahead and "just do it" once they realize the most basic requirements are met and they have the resource already literally in their hands. Or they won't. It really doesn't matter. What does matter is that they'll have it for the day when it becomes in their interest to do so on short order. How many more participants in IPv6 day do you think there would have been if address blocks were just laying around waiting to be deployed by excited network engineers? > 2. The concept requires that IPv6 resources come from ARIN, but > there may be other sources of v6 addresses such as an upstream, or a > global organization has an IPv6 allocation from a different RIR; > they should not be required to obtain their IPv6 space from ARIN. Please substitute the term IPv4 for IPv6 in the above and re-read. Done? Good. An organization who can justify an IPv4 allocation from ARIN is surely in the same position to justify an IPv6 allocation from ARIN for the same network. > Maybe instead you want to add a requirement that IPv4 allocations for > new networks be in compliance with RFC 6540, and the applicant to > receive v4 by new allocation or by transfer show this, if they are > not also applying for v6 address space.. If this did not work for the homogeneous and hierarchical US Department of Defense, it surely will not work for the heterogeneous rest of us. > 6to4 gateways are not necessarily an advisable migration strategy. Why not? It's widely deployed and proven effective. Further, it fits perfectly with the concepts of end-to-end connectivity, the role of routing infrastructure, and is easily understood: "Ohh, so the entire IPv4 internet fits into this nice little 2002:: chunk and I get all these addresses mapped for free? Got it. And my hardware and software already do this? Cool. How do I turn it on?" > 4to4 / CGN has significant advantages. Are you're seriously advocating NAT444? Allow me to condense the long investigation into why this is bonkers by generalizing the wrongness into one very simple statement: Nothing -- and I mean nothing -- along the path should be molesting my packet in any way whatsoever. As corollaries: You do not steal bits from a field of a deeper layer in order to pretend that you have a larger network address space. You do not handle routing by introducing stateful information from outside the network layer. And as a frank aside, how is it that I can hear a carrier whine about how the BGP table is getting unmanageably large while at the same time hearing him advocating for what amounts to introducing and consistently tracking a thousand little state entries per /32? Yeah, I know the difference between core and border. But there's obviously a serious mental disconnect here. > > - Actually bother to pronounce an IPv4 deprecation date. Only some weak > > It would be inappropriate at this time for ARIN to announce a > deprecation date for Well, then don't phrase it as deprecation. ARIN seems to have no problem regularly proclaiming IPv4 address exhaustion. How about sunsetting the handling of requests for any actions related to IPv4 allocations? "What's out there is what's out there. We're washing our hands of it." > IPv4 or IPv4 addressing. It's not a RIR's place to do that; > it's IETF's. Is it? The IETF is an standards body. ARIN is an operating body. You probably meant IANA. And speaking of saying, "What's out there is what's out there. We're washing our hands of it." The only way they'll probably get involved in IPv4 again is if through some seemingly impossible turn of events one of the RIRs relinquishes a /8 for one of the others to fight over. > If ARIN were to decide they wanted to get out of IPv4 addressing prematurely, > it would be time at that point for them to be replaced as RIR for IPv4. If ARIN is still primarily screwing around with IPv4 in 2019, perhaps this is indeed the most appropriate course of events. > It's amazing that despite the enormous amount of evidence to the contrary, > people keep regurgitating the totally unfounded myth that markets > provide the good > solution to all problems. Sigh. > If this were true, TCP/IP would not be deployed very much, > because it would > never have caught on; the market would have recognized this problem, > and prevented > TCP/IP from succeeding. Instead most networks would be using the > best closed proprietary (and therefore most lucrative) replacement for > TCP/IP that the market had brought us, which would have no IP > address resource exhaustion problem from the beginning. Actually, no, the market is what caused the success of TCP/IP. Dig up someone (sadly, this may require a literal interpretation) from Novell, DEC, or Apple and ask about how that all happened. Yes, I understand that it's easier to generate and disappear into the smoke and miasma settled over the field of economics. But you'll notice that I have not yet made even one suggestion economically rooted. So, what do you say that we just leave economics as the aside it was intended to be. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From tvest at eyeconomics.com Sat May 12 21:42:59 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Sat, 12 May 2012 21:42:59 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> Message-ID: <7AF12B36-4567-4DCD-82E8-0EECA1E53702@eyeconomics.com> On May 12, 2012, at 12:06 PM, Owen DeLong wrote: >>> - Actively promote the establishment and maintenance of 6to4 gateways by >>> all present IPv4 allocation holders above a sensibly arbitrary size, >> >> 6to4 gateways are not necessarily an advisable migration strategy. >> 4to4 / CGN has significant advantages. >> > > 6to4 gateways aren't so much a migration strategy as a way to connect IPv6 islands across an IPv4 ocean. > > 4to4/CGN offer an alleged solution to a completely different problem -- How to multiplex more IPv4 connections onto a single IPv4 address. (Also not a migration strategy, but instead a strategy for attempting to avoid migration.) Frankly, anyone who has looked at the details of CGN and truly considered the problems of CGN would prefer to do native IPv6 with CGN providing only the minimal amount of connectivity to unfortunate IPv4 only end-points and would be actively seeking to encourage popular IPv4 only end-points to add IPv6 capabilities as quickly as possible. > > The alternatives which could be called a migration strategy are NAT64/DNS64 which provides a mechanism for an IPv6-only host to make an IPv6 connection to a proxy host which "NATs" that connection (it's really more like a proxy) to an IPv4 connection to the true destination and DS-LITE which tunnels IPv4 private addresses over the providers IPv6 network to a CGN NAT44 box. > > All of these so-called solutions have tradeoffs and the only one which does not provide a degraded user experience is dual-stacked content providers during the transition period with the eventual goal of native IPv6 everywhere. > >> >>> - Actually bother to pronounce an IPv4 deprecation date. Only some weak >> >> It would be inappropriate at this time for ARIN to announce a >> deprecation date for >> IPv4 or IPv4 addressing. It's not a RIR's place to do that; >> it's IETF's. >> > > Good luck getting the IETF to come to consensus on that one. > >> If ARIN were to decide they wanted to get out of IPv4 addressing prematurely, >> it would be time at that point for them to be replaced as RIR for IPv4. >> > Agreed. > >> >>> Indeed. I'd revisit his suggestions. A market, when left to its >>> devices, solves these problems with remarkable speed and little >> [snip] >> >> It's amazing that despite the enormous amount of evidence to the contrary, >> people keep regurgitating the totally unfounded myth that markets >> provide the good >> solution to all problems. >> > +1 > >> If this were true, TCP/IP would not be deployed very much, >> because it would >> never have caught on; the market would have recognized this problem, >> and prevented >> TCP/IP from succeeding. Instead most networks would be using the >> best closed proprietary (and therefore most lucrative) replacement for >> TCP/IP that the market had brought us, which would have no IP >> address resource exhaustion problem from the beginning. > > Here, I think you drive off the rails a bit. Open Source can be the most > efficient and most lucrative solution to a problem and a market can and > has recognized that efficiency many times (Linux, Apache, SSH). > > Just because markets are often wrong (X11, Motif, Windows, Enron, > Tulips, Housing) does not mean that they always are. Hi Owen, Though I am in wholehearted agreement with both of your general points (about markets and open source), as well as with your your specific (counter)examples, I think that it is worth contemplating whether TCP/IP might never had achieved critical mass in the absence of the unique distribution mechanisms and principles that were ultimately, roughly codified in RFC2050 and institutionalized in the form of the "RIR system." My own interpretation of the historical record suggests that the interests who favored different, proprietary routing and addressing technologies (including both the proprietors themselves as well as the established telecom SSOs where their views went unchallenged), and who at that time embraced TCP/IP as, at best, an optional inter-networking feature that could be superficially bolted onto their own proprietary networking platforms, were still dominant almost everywhere except the United States at the time when the first RIRs appeared in Europe and Asia. I believe that the limited geographic devolution of the critical protocol resource distribution and policy-making authority that began with the establishment of RIPE NCC substantially reduced both the number and severity/cost of barriers to establishing and expanding a TCP/IP-based network -- rather than, say, a DECnet, SNA, or some other proprietary network -- and that those relative advantages played no small role in determining TCP/IP's subsequent path to absolute global market dominance. Conceivably, one could argue that TCP/IP would eventually have achieved that same dominant status by some other path -- e.g., if the inherent superiority of TCP/IP protocols, or the growing market power of US-based, TCP/IP-favoring hardware manufacturers and/or network services providers would have eventually proven irresistible even in a world in which TCP/IP was just a parochial US-only standard -- despite the fact that prospective TCP/IP adoptees would have understood that choosing TCP/IP would make them perpetually dependent on some US-based entity -- either a USG contractee, or more likely GE, Halliburton, or one of the other early private entities who obtained classful IPv4 before its c. 1994-1995 exhaustion. Or perhaps HP, Dell, IBM, et al. and the telco-era SSOs would have eventually embraced "open access" approaches toward inter/networking protocol resources than were similar to or even stronger than the "needs based" practices pioneered by RIR system participants -- or barring that, maybe a whole new generation of open source-favoring hardware manufacturers would have inevitably sprung up somewhere, and inevitably competed all of the dominant, closed-network/protocol-favoring manufacturers and service providers into submission, or bankruptcy... Anything's possible I guess, but speaking as someone who was born in the 20th century, and who has benefited a great deal from the existence of a working Internet during my lifetime, I'm very glad that we didn't have to wait to find out whether one of those other highly improbable sequences would have eventually panned out. Speculatively, TV From izaac at setec.org Sat May 12 22:29:20 2012 From: izaac at setec.org (Izaac) Date: Sat, 12 May 2012 22:29:20 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> Message-ID: <20120513T020621Z@localhost> On Fri, May 11, 2012 at 01:31:29PM -0400, William Herrin wrote: > As I recall there were three main reasons why not: > > 1. Although we insist folks need to deploy IPv6, we couldn't possibly > assign them addresses until they publicly state the truth of our > belief by making a paid application. When I say things like "encourage," the waiving or reduction of fees in certain circumstances seems to apply. Unless of course one of the armchair economists like to argue the efficacy of subsidy and efficacy to affect the behavior of applicants? > 2. The preemptive block might possibly not be the right size, leading > to a request for a second block and an entire extra route in the IPv6 > BGP table. Never mind that it turns out somewhere between many and > most of the initial IPv6 allocations have ended up being the wrong > size anyway. As if the possibility that wouldn't happen had every been > more than wishful thinking. In my opinion, if you can't fit your world into a /56 or /48, you're doing something very, very wrong. But hey, I get that stuff happens. > 3. Per the IETF, all IPv6 end users are supposed to get IPs from their > ISP, even though the technical basis for that plan has been thoroughly > discredited for more or less every situation in which a registrant > qualifies to hold ARIN IPv4 addresses. So, in summary, all three arguments are weaker than a quadriplegic poodle. Gotcha. Thanks. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From drake.pallister at duraserver.com Sat May 12 23:17:48 2012 From: drake.pallister at duraserver.com (Drake Pallister) Date: Sat, 12 May 2012 23:17:48 -0400 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in caseof Bankruptcy References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com><4FAAD7B7.4050701@arin.net><5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca><4FAC4ECE.2090205@gmx.com><8695009A81378E48879980039EEDAD28012075D341@MAIL1.polartel.local> Message-ID: <489B906DB4054670A9F3017E7A7F4269@dp9100> Hello Gentlemen, Ah the holding pen is another good name for a place to keep the resources safe during any proceedings. I agree that there is a need for endangered resources to be kept operational during the disposition of the company using them. There are a few reasons they should be kept alive. Non-disruption of services to end users is way up there. In the event of a cableco, that could be many cities of citizens. Or a different ISP may have mission-critical operations riding on it. Though if it were a medical mission-critical, I'd hope they were supplied from two non-related sources, but who knows. We've all heard stories where a triple-redundant network was designed and services purchased through 3 vendors unknowing that at some point in the path, the 3 redundancies routed through one upstream ISP. It can happen and it has happened. During whacky financial or legal proceedings, assets can be lost, squandered, impounded, etc., even due to mistakes or poor judgment. To have a place for "resources" to be kept safely distant from the "assets" should be considered so they don't accidentally be construed or mistaken as assets. There's always a chance for a company to pull itself out of a mess. Then, at least the "resources" had been kept a safe distance from the battle for the company to retrieve or the companies who legitimately pick up the pieces. Here's a snip from my May 10 snip. [snip] As I have mentioned in another list posting, I'd surely recommend that ARIN examine the situation where ASN's or IP allocations are pulled back into their safe haven, and allow for the continued Internet routing and propagation of such "safe haven" ASN's or IP allocations to: 1.) not cause further devaluation to the endangered entity by disconnection of its subscriber base; 2.) assist in the non-disruption of IP services of the endangered company's end user customer, hence the general public; 3.) protect the physical integrity of such "safe haven"ASN's or IP allocations in the event the troubled entity successfully pulls itself out of its troubled condition; 4.) make administrative judgments of the ASN's or allocation's should the troubled company go to the point of liquidation. (2 and 3 being of a higher ethical importance) [end snip] (And such a service, holding pen, safe harbor, whatever--- should not be dumped on ARIN to safeguard for free) Since it's not just the resources that make the Internet function, someone would be paying for electronic gear, NOC space, circuits, and bandwidth to keep the troubled company's network running during its demise or repair. With all respect, Drake Pallister ----- Original Message ----- From: "Jimmy Hess" To: "Kevin Kargel" Cc: Sent: Friday, May 11, 2012 11:58 PM Subject: Re: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in caseof Bankruptcy > On 5/11/12, Kevin Kargel wrote: > [snip] >> The problem I see is that the resource may need to stay in operation >> during >> the acquisition process to retain value. For example if a local cable > [snip] > > Not only will the AS most likely need to stay in operation during an > acquisition process, > but ARIN must provide the accurate WHOIS data for the AS as long as it > is in operation, so that the appropriate contacts can be properly > reached if there are any issues related to the AS. > > Temporarily "delisting an AS" or any number resource still in > operation is really just not proper. > > -- > -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 owen at delong.com Sun May 13 01:05:45 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 12 May 2012 22:05:45 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <20120513T020621Z@localhost> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On May 12, 2012, at 7:29 PM, Izaac wrote: > On Fri, May 11, 2012 at 01:31:29PM -0400, William Herrin wrote: >> As I recall there were three main reasons why not: >> >> 1. Although we insist folks need to deploy IPv6, we couldn't possibly >> assign them addresses until they publicly state the truth of our >> belief by making a paid application. > > When I say things like "encourage," the waiving or reduction of fees > in certain circumstances seems to apply. Unless of course one of the > armchair economists like to argue the efficacy of subsidy and efficacy > to affect the behavior of applicants? > There are already fee reductions in place for IPv6 allocations and have been for years. >> 2. The preemptive block might possibly not be the right size, leading >> to a request for a second block and an entire extra route in the IPv6 >> BGP table. Never mind that it turns out somewhere between many and >> most of the initial IPv6 allocations have ended up being the wrong >> size anyway. As if the possibility that wouldn't happen had every been >> more than wishful thinking. > > In my opinion, if you can't fit your world into a /56 or /48, you're > doing something very, very wrong. But hey, I get that stuff happens. > If you're a single end-site, then a /48 should be fine in almost every case, if not every case. If you are an end-user with a campus or multiple campuses that have multiple end-sites each, then you need a /48 for each end-site to do things properly. (Note, end-sites may actually be defined by natural network aggregation points in topology and not actual physical buildings, but, a /48 per building or per tenant in a multi-tenant building serves as a pretty good rule of thumb in either case.) However, if you are giving out /48s to the end-sites you serve as an ISP and some of your customers may have multiple end-sites, then you may not even fit in a /32. For example, Hurricane Electric has definitely outgrown its /32 and has (thankfully) received a /24 for growing our network which will serve us quite nicely for many years to come. >> 3. Per the IETF, all IPv6 end users are supposed to get IPs from their >> ISP, even though the technical basis for that plan has been thoroughly >> discredited for more or less every situation in which a registrant >> qualifies to hold ARIN IPv4 addresses. I think this was stated mostly tongue in cheek. > > So, in summary, all three arguments are weaker than a quadriplegic > poodle. Gotcha. Thanks. No, not really. You also left out argument 4 which is that it does not make sense to assign unrequested addresses because people that qualify for and need IPv4 addresses from ARIN may already have sufficient IPv6 addresses from some other source. While they could qualify for IPv6 addresses from ARIN, if they have absolutely no need for them and have already deployed their IPv6 using addresses from another source, what possible good comes from giving them ARIN IPv6 addresses that they don't need or want? Owen From tvest at eyeconomics.com Sun May 13 02:04:24 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Sun, 13 May 2012 02:04:24 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <355627CB-86ED-4F19-BCB8-9D17837AEE1B@delong.com> 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> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <7AF12B36-4567-4DCD-82E8-0EECA1E53702@eyeconomics.com> <355627CB-86ED-4F19-BCB8-9D17837AEE1B@delong.com> Message-ID: <766C7055-B11F-4818-A54C-3922044C370A@eyeconomics.com> On May 13, 2012, at 12:59 AM, Owen DeLong wrote: >> >> Hi Owen, >> >> Though I am in wholehearted agreement with both of your general points (about markets and open source), as well as with your your specific (counter)examples, I think that it is worth contemplating whether TCP/IP might never had achieved critical mass in the absence of the unique distribution mechanisms and principles that were ultimately, roughly codified in RFC2050 and institutionalized in the form of the "RIR system." My own interpretation of the historical record suggests that the interests who favored different, proprietary routing and addressing technologies (including both the proprietors themselves as well as the established telecom SSOs where their views went unchallenged), and who at that time embraced TCP/IP as, at best, an optional inter-networking feature that could be superficially bolted onto their own proprietary networking platforms, were still dominant almost everywhere except the United States at the time when the first RIRs appeared in Europe and Asia. I believe that the limited geographic devolution of the critical protocol resource distribution and policy-making authority that began with the establishment of RIPE NCC substantially reduced both the number and severity/cost of barriers to establishing and expanding a TCP/IP-based network -- rather than, say, a DECnet, SNA, or some other proprietary network -- and that those relative advantages played no small role in determining TCP/IP's subsequent path to absolute global market dominance. >> > > I absolutely agree. However, I'm not sure how that differs from what I was saying, if you believe that it does. > To me, it seems like another way of saying "not only is a market likely to be harmful to what we have achieved here, but, had we started with a market, we would likely have never achieved widespread adoption. > >> Conceivably, one could argue that TCP/IP would eventually have achieved that same dominant status by some other path -- e.g., if the inherent superiority of TCP/IP protocols, or the growing market power of US-based, TCP/IP-favoring hardware manufacturers and/or network services providers would have eventually proven irresistible even in a world in which TCP/IP was just a parochial US-only standard -- despite the fact that prospective TCP/IP adoptees would have understood that choosing TCP/IP would make them perpetually dependent on some US-based entity -- either a USG contractee, or more likely GE, Halliburton, or one of the other early private entities who obtained classful IPv4 before its c. 1994-1995 exhaustion. Or perhaps HP, Dell, IBM, et al. and the telco-era SSOs would have eventually embraced "open access" approaches toward inter/networking protocol resources than were similar to or even stronger than the "needs based" practices pioneered by RIR system participants -- or barring that, maybe a whole new generation of open source-favoring hardware manufacturers would have inevitably sprung up somewhere, and inevitably competed all of the dominant, closed-network/protocol-favoring manufacturers and service providers into submission, or bankruptcy... > > I think that by and large, TCP/IP won because it came with zero vendor baggage. Any vendor was free to implement it without fear of giving a competitive advantage to their competing vendors. No other protocol offered this possibility. While the moneyed interests were definitely carrying on their proprietary protocols, > to be sure, they were faced with groups of companies that wanted interoperability between their networks no matter whether they bought from Novell, Banyan, DEC, or whoever. As a result, each of them was willing to bolt-on TCP/IP as this optional add-on (sometimes at significant cost) to enable those minimal inter-company connections where necessary. > > Where I think that the InterNIC and later the RIR system triumphed is that it presented a low-friction low-cost mechanism for distribution of addresses (RIRs actually added, not reduced friction and cost vs. InterNIC, btw) that still provided reliable global uniqueness. Had the InterNIC and later the RIR system not succeeded in that mission, TCP/IP would likely be several different fragmented administrative zones with odd NAT boundaries connecting them. Sounds like we're in complete agreement on the main points. The specific point that I was trying to highlight (the independent significance of which we may differ slightly) was that, contra the markets-fix-everything comments that preceded yours, TCP/IP would probably have looked either a lot less useful or a lot more vendor baggage-laden (or both) by the mid-1990s -- that is, if "needs based" distribution mechanisms had not been formalized and geographically distributed around that time. I have no doubts about the greater ease of interacting with InterNIC relative to its successors (esp. for English-speaking residents of adjacent timezones), and I know that opinions still differ among some who were more than just present at the creation regarding the merits of the geographic part of that equation. That said, from what I know of the relevant chain(s) of events outside the US, I would venture that whatever marginal friction has resulted from the regionalization of number resource management pale into insignificance when compared to the frictions that would have been endemic in a world without open access to open source interdomain routing protocols. IMO, given what was at stake and the uncertainty of the outcome at that time, it still looks like it was the smartest bet. >> Anything's possible I guess, but speaking as someone who was born in the 20th century, and who has benefited a great deal from the existence of a working Internet during my lifetime, I'm very glad that we didn't have to wait to find out whether one of those other highly improbable sequences would have eventually panned out. > > I couldn't agree more, but, having lived as a network engineer through much of that history and transition, it seems we have divergent memories of the exact chain of events. > > Owen That's okay Owen; we have plenty of time to work on that ;-) Regards, TV From jcurran at arin.net Sun May 13 07:28:39 2012 From: jcurran at arin.net (John Curran) Date: Sun, 13 May 2012 11:28:39 +0000 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in caseof Bankruptcy In-Reply-To: <489B906DB4054670A9F3017E7A7F4269@dp9100> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> <4FAC4ECE.2090205@gmx.com> <8695009A81378E48879980039EEDAD28012075D341@MAIL1.polartel.local> <489B906DB4054670A9F3017E7A7F4269@dp9100> Message-ID: On May 12, 2012, at 11:17 PM, Drake Pallister wrote: > Ah the holding pen is another good name for a place to keep the resources safe during any proceedings. Mr. Pallister - In many ways, a "holding pen" is what occurs already in bankruptcy proceedings with respect to contracts and services, as the courts will require uninterrupted services in many cases to avoid impact to the estate. This is done under supervision of the bankruptcy court, as it has jurisdiction in these matters which comes first. Please reference attached email regarding taking actions specific to resources entering bankruptcy proceedings. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: > From: John Curran > Subject: Re: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy > Date: May 11, 2012 10:08:42 AM EDT > To: Kevin Kargel > Cc: Owen DeLong , Astrodog , "arin-ppml at arin.net" > > On May 11, 2012, at 6:38 AM, Kevin Kargel wrote: > >> The trick to all this is that it needs a trigger. I rather doubt that any >> operation is going to jump up and notify ARIN when they start a bankruptcy, >> rather they will start conversations with ARIN when numbers actually need >> attention. > > There are some much larger issues than just notification; > in particular, bankruptcy courts generally take precedence > in any actions against an estate, and ARIN may easily be > required to obtain the courts explicit permission before > doing anything with respect to the number resources. > > It is very challenging to devise contract terms and policy > language specifically for bankruptcy estates, since the entire > idea of bankruptcy is to prevent any potential asset from > leaving the estate, instead protecting it until the process can > arrange for obtaining maximum value to be divided up > among the creditors. > > Establishing specific policies for bankruptcy has complex > legal aspects; if policy is proposed in this area, we will > endeavor to get appropriate level of legal review. > > Thanks! > /John > > John Curran > President and CEO > ARIN From izaac at setec.org Sun May 13 07:41:22 2012 From: izaac at setec.org (Izaac) Date: Sun, 13 May 2012 07:41:22 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: <20120513T104756Z@localhost> On Sat, May 12, 2012 at 10:05:45PM -0700, Owen DeLong wrote: > > In my opinion, if you can't fit your world into a /56 or /48, you're > > doing something very, very wrong. But hey, I get that stuff happens. > > If you're a single end-site, then a /48 should be fine in almost every case, > if not every case. > > If you are an end-user with a campus or multiple campuses that have multiple > end-sites each, then you need a /48 for each end-site to do things properly. > (Note, end-sites may actually be defined by natural network aggregation points > in topology and not actual physical buildings, but, a /48 per building or per > tenant in a multi-tenant building serves as a pretty good rule of thumb in either case.) > > However, if you are giving out /48s to the end-sites you serve as an ISP and > some of your customers may have multiple end-sites, then you may not even > fit in a /32. For example, Hurricane Electric has definitely outgrown its /32 and > has (thankfully) received a /24 for growing our network which will serve us > quite nicely for many years to come. Yes. I would hope that an ISP requesting space at that level would not need to be compelled to present a commensurate IPv6 allocation request. I suspect, though, that there are any number of multi-homed and end-user requesters seeking /20's and longer that simply have not bothered to consider transition at all. Or I may be wrong. But there's probably no way to tell for sure right now. I'd love to see a summer researcher or intern at ARIN try to match up IPv4 and IPv6 allocations and generate a report. It could be delivered along-side the real exhaustion announcement I expect sometime around Thanksgiving or Christmas. Is there a box pool that I can get in on for this, by the way? Maybe NANOG has one. Hmm. > I think this was stated mostly tongue in cheek. I assumed that all three were tongue in cheek. > No, not really. You also left out argument 4 which is that it does not make > sense to assign unrequested addresses because people that qualify for and > need IPv4 addresses from ARIN may already have sufficient IPv6 addresses > from some other source. While they could qualify for IPv6 addresses from ARIN, > if they have absolutely no need for them and have already deployed their > IPv6 using addresses from another source, what possible good comes from > giving them ARIN IPv6 addresses that they don't need or want? I like argument four; it makes sense. You're quite right. If you've already got IPv6 space allocated (and especially in use) to cover those newly requested IPv4 blocks, you shouldn't need any more. And it should be trivial to attach a quick, formulaic report stating such to meet a hypothetical commensurate-IPv6-rule. On the other hand, if you have a requester coming back for another /20 because of network growth or topology change or whatever, is it not reasonable to expect that their previous expectations on the IPv6-side have also changed? If he's sitting on a ::/32, I'd hope that 64ki of ::/48s is enough to cover all the little /29s into which he hopes to carve that shiny new /20. But as you suggest above, maybe not. Fortunately, men and women far better than I are available and in position to suss out the details of policies. It allows me to remain some cranky jerk that lobs crudely formed lumps of concept at mailing lists which he normally doesn't even read in real-time -- except that he broke his procmailrc. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From bill at herrin.us Sun May 13 11:54:38 2012 From: bill at herrin.us (William Herrin) Date: Sun, 13 May 2012 11:54:38 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On 5/13/12, Owen DeLong wrote: > argument 4 which is that it does not make > sense to assign unrequested addresses because people that qualify for and > need IPv4 addresses from ARIN may already have sufficient IPv6 addresses > from some other source. Hi Owen, So what? As you were fond of point out in the discussions about 6rd, -there is no impending shortage of IPv6 addresses-. Giving every holder of an ARIN AS a /32 would burn only a /17. It'd still only consume a /14 if you want three bits of headroom (sparse allocation) so that those folks can expand without renumbering or introducing extra routes into BGP. Weigh this against the cost of delay. Folks very obviously aren't deploying at the speed you'd like to see. Dealing with ARIN is one of the many obstructions to doing so, as is finding the funding for something "we don't need this month." If we gain speedier deployment and the potential loss is capped at a single /14 of IPv6 address space, how is preemptive assignment not a huge win? > There are already fee reductions in place for IPv6 allocations and have > been for years. Not for end users which is where you main resistance is coming from. ISPs will deploy IPv6 when they're customers include its presence or absence in their contracting decisions. End users will deploy either when they feel like it or after everybody else does. > On May 12, 2012, at 7:29 PM, Izaac wrote: >> So, in summary, all three arguments are weaker than a quadriplegic >> poodle. Gotcha. Thanks. Hi Izaac, That's my opinion, yes. I find the "they might not use it" argument lacking as well. Our supposed goal is for folks to deploy and use IPv6. They for 100% certain won't use the addresses until after addresses have been assigned. If you're holding an ARIN AS number, there's a 90%+ likelihood you're using addresses in a way that is not fully compatible with an ISP assignment. You might tinker with ISP addresses (just as you might tinker with 6to4 addresses) but you're not going to deploy until after you have RIR addresses. If we wanted to pinch pennies, we could get the job done and still limit preemptive assignment to organizations which actually use their ARNI AS on the public Internet *and* don't already either hold ARIN IPv6 addresses or announce addresses from another RIR using one of their AS numbers into the Internet BGP table. That'd save at least one bit. Doing so, however, would raise ARIN's cost: they'd have to do a real analysis of the registrants instead of trivially pulling "all registrants with an AS number." All to save a fraction of a one-time assignment of less than a /14 of IPv6 address space. 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 Sun May 13 13:24:13 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 13 May 2012 12:24:13 -0500 Subject: [arin-ppml] ARIN-prop-170 Transfer of Number Resources in caseof Bankruptcy In-Reply-To: <489B906DB4054670A9F3017E7A7F4269@dp9100> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> <4FAC4ECE.2090205@gmx.com> <8695009A81378E48879980039EEDAD28012075D341@MAIL1.polartel.local> <489B906DB4054670A9F3017E7A7F4269@dp9100> Message-ID: On 5/12/12, Drake Pallister wrote: > During whacky financial or legal proceedings, assets can be lost, > squandered, impounded, etc., even due to mistakes or poor judgment. To have > a place for "resources" to be kept safely distant from the "assets" should > be considered so they don't accidentally be construed or mistaken as assets. [snip] The best way for ARIN to prevent a resource it assigns being considered as assets, is to make sure the agreements under which they are allocated and maintained are solid. Perhaps there should just be a one or two-line disclaimer in the ARIN WHOIS listing for every registration, in addition to the TOU reference. example "* The following is operational contact information that has been reported to ARIN by a subscriber assigned or allocated internet number resources as required by ARIN region Number Resource Policies. The listed contact is not the owner or registrant of the listed number resources. ARIN does not endorse or guarantee the accuracy of WHOIS contact details." The agreements ARIN requires resource holders sign should solidify -- that the allocation and assignment of number resources do not convey any permanent ownership, do not confer any permanent or transferrable right or privilege to shared or exclusive use, do not confer any other rights that can be transferred, do not provide any rights that ARIN cannot revoke, that each allocation must be renewed every year with payment of fees, and ARIN may cancel any allocation, or refuse the renewal or transfer of any allocation. -- -JH From jcurran at arin.net Sun May 13 14:05:49 2012 From: jcurran at arin.net (John Curran) Date: Sun, 13 May 2012 18:05:49 +0000 Subject: [arin-ppml] ARIN Registration Agreements (was: ARIN-prop-170 Transfer of Number Resources in caseof Bankruptcy) In-Reply-To: References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> <4FAC4ECE.2090205@gmx.com> <8695009A81378E48879980039EEDAD28012075D341@MAIL1.polartel.local> <489B906DB4054670A9F3017E7A7F4269@dp9100> Message-ID: <7F1ADA59-9DB9-4528-812B-69333C0497C3@corp.arin.net> On May 13, 2012, at 1:24 PM, Jimmy Hess wrote: > The agreements ARIN requires resource holders sign should solidify -- > that the allocation and assignment of number resources do not convey > any permanent ownership, do not confer any permanent or transferrable > right or privilege to shared or exclusive use, do not confer any > other rights that can be transferred, do not provide any rights that > ARIN cannot revoke, that each allocation must be renewed every year > with payment of fees, and ARIN may cancel any allocation, or > refuse the renewal or transfer of any allocation. Jimmy - The registration services agreements are routinely updated and generally go out for community consultation before any significant change. While the current consultation periods are closed, please feel free to review the RSA version 11 or LRSA version 3 agreements (they are very similar at this point), and send any suggestions for changes to me for consideration in future revisions. I'll think you will find much of your statements above to be already in place. Thanks! /John John Curran President and CEO ARIN p.s. RSA 11 consultation - https://www.arin.net/announcements/2012/20120312.html LRSA 3 consultation - https://www.arin.net/announcements/2011/20111027.html From mysidia at gmail.com Sun May 13 14:30:37 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 13 May 2012 13:30:37 -0500 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <20120513T004128Z@localhost> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T004128Z@localhost> Message-ID: On 5/12/12, Izaac wrote: > their interest to do so on short order. How many more participants in > IPv6 day do you think there would have been if address blocks were just > laying around waiting to be deployed by excited network engineers? Hm... every 10-digit phone numther in the NANP can be represented using 34 bits. Perhaps an IPv6 /14 should be allocated, from which ANY organization may populate 34 bits with a permanent 10-digit contact telephone number, and derive a /48 that they may use globally, without needing to submit an application. -- -JH From paul at redbarn.org Sun May 13 17:22:29 2012 From: paul at redbarn.org (paul vixie) Date: Sun, 13 May 2012 21:22:29 +0000 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T004128Z@localhost> Message-ID: <4FB02615.3060303@redbarn.org> On 5/13/2012 6:30 PM, Jimmy Hess wrote: > On 5/12/12, Izaac wrote: >> their interest to do so on short order. How many more participants in >> IPv6 day do you think there would have been if address blocks were just >> laying around waiting to be deployed by excited network engineers? > Hm... every 10-digit phone numther in the NANP can be represented using > 34 bits. > >> Perhaps an IPv6 /14 should be allocated, from which ANY organization may populate 34 bits with a permanent 10-digit contact telephone number, and >> derive a /48 that they may use globally, without needing to submit an application. do you mean like unique local addresses (RFC 4193) or do you mean more like ULA-Global (http://nsa.vix.com/~vixie/ula-global.txt) ? paul -- "I suspect I'm not known as a font of optimism." (VJS, 2012) From cgrundemann at gmail.com Sun May 13 17:18:28 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sun, 13 May 2012 15:18:28 -0600 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On Sun, May 13, 2012 at 9:54 AM, William Herrin wrote: > If we gain speedier deployment and the potential loss is capped at a > single /14 of IPv6 address space, how is preemptive assignment not a > huge win? It's not a huge win because it won't make any appreciable difference, it's not actually a win at all. Let's ask the real question here: How does blindly assigning IPv6 to organizations provide any additional motivation to deploy IPv6? If today I don't think I need to deploy IPv6, and tomorrow I have an IPv6 block assigned to me out of the blue, how does that change my mind about deploying IPv6 in any way? Yes reducing barriers lowers cost, but the barrier you are proposing to remove is a very low one, perhaps insignificant to the total cost of IPv6 deployment. What is likely more effective from an RIR perspective is adding motivation instead. One possible idea would be for the officer attestation of accuracy already required for every request of address space be broadened in the case of an IPv4-only applicant (an applicant requesting IPv4 who does not have a previous IPv6 assignment/allocation) to include acknowledgement of the state of IPv4 free pools (IANA empty, ARIN approaching exhaustion, etc) and the IETF published best practice that all Internet services require both IPv4 and IPv6 capabilities (RFC 6540 - IPv6 Support Required for All IP-Capable Nodes) and other similar facts. At the very least we would then ensure that at least one officer of each address holder was aware of the significant motivations to deploy IPv6 sooner rather than later. We could also revisit the formerly unpopular idea of requiring IPv6 deployment in order to obtain additional IPv4 addresses... > _______________________________________________ > 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 mysidia at gmail.com Sun May 13 17:33:49 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 13 May 2012 16:33:49 -0500 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: <4FB02615.3060303@redbarn.org> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T004128Z@localhost> <4FB02615.3060303@redbarn.org> Message-ID: On 5/13/12, paul vixie wrote: > do you mean like unique local addresses (RFC 4193) or do you mean more > like ULA-Global (http://nsa.vix.com/~vixie/ula-global.txt) ? No, ULA addresses are designed to only be locally reachable. The abstract you referred says "These addresses are globally unique and are intended for local communications, usually inside of a site. They are not intended or expected to be routable on the global Internet." I mean like globally unique addresses provided which are also global unicast and do not have a "Local Reachability" restriction, so you can prepare in advance of your IPv6 deployment, since you know what your allocation will be, and register full contact details with the relevant registry as soon as your ready to route them, without any requirement for an application process. With a simple verification process, specifically: the registry can call the phone number and provide a confirmation code to be used to setup the assignment contact details via web site. > paul -- -JH From mysidia at gmail.com Sun May 13 17:53:23 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 13 May 2012 16:53:23 -0500 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On 5/13/12, Chris Grundemann wrote: > On Sun, May 13, 2012 at 9:54 AM, William Herrin wrote: >> If we gain speedier deployment and the potential loss is capped at a >> single /14 of IPv6 address space, how is preemptive assignment not a >> huge win? > It's not a huge win because it won't make any appreciable difference, > it's not actually a win at all. It removes a barrier in IPv6 deployment; which is not just about cost, but also about time and paperwork. It also greatly simplifies the allocation of addresses, and therefore eliminates address space management overhead expenses for the RIR. Carve one /14 to represent /48 end-user assignments a priori based on telephone number. Carve one /8 to represent a IPv6 /24 end-user assignment for each 16-bit AS number. Any allocation made in an unstructured way is then a "special allocation" > Let's ask the real question here: How does blindly assigning IPv6 to > organizations provide any additional motivation to deploy IPv6? If It takes away and excuse not to deploy IPv6. > We could also revisit the formerly unpopular idea of requiring IPv6 > deployment in order to obtain additional IPv4 addresses... Added barriers to deployment of IPv4 without IPv6 is also a possibility. But based on your argument.... just obtaining the addresses doesn't mean they will deploy IPV6. They may simply obtain IPv6 addresses, without deploying them, so that their burden of obtaining more IPv4 resources is reduced. Perhaps we should have a 3 month SUPPLY rule on both allocations and transfers for organizations that have not demonstrated IPV6 deployment, A 12 months of IPv4 resources supply rule on allocations and transfers to organizations that have demonstrated at least 30% IPv6 deployment. -- -JH From bill at herrin.us Sun May 13 21:33:05 2012 From: bill at herrin.us (William Herrin) Date: Sun, 13 May 2012 21:33:05 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On 5/13/12, Chris Grundemann wrote: > On Sun, May 13, 2012 at 9:54 AM, William Herrin wrote: >> If we gain speedier deployment and the potential loss is capped at a >> single /14 of IPv6 address space, how is preemptive assignment not a >> huge win? > > It's not a huge win because it won't make any appreciable difference, > it's not actually a win at all. > > Let's ask the real question here: How does blindly assigning IPv6 to > organizations provide any additional motivation to deploy IPv6? If > today I don't think I need to deploy IPv6, and tomorrow I have an IPv6 > block assigned to me out of the blue, how does that change my mind > about deploying IPv6 in any way? I sit on a peering exchange at one of my sites. It's a layer-2 switch. The only obstruction to peering on the exchange is that the exchange's owner needs to assign IPv6 addresses. Which they don't presently have. They're waiting for higher demand before doing the paperwork and coughing up the cash. Nor is this situation unique. Two of my three networks have not done anything with IPv6. IPv6 is so poorly used right now that I can't justify the expense for the addresses to the customers. I could spend the time as an idle priority project and it would get done. But I can't spend the money. Not yet. Not until IPv6 is much more heavily used. > Yes reducing barriers lowers cost, but the barrier you are proposing > to remove is a very low one, perhaps insignificant to the total cost > of IPv6 deployment. What is likely more effective from an RIR > perspective is adding motivation instead. Plan A: Debate, argue, maybe even analyze how significant or insignificant a barrier we're talking about. Plan B: Remove the barrier. Look back later to see whether it had an impact. 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 Sun May 13 22:23:57 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 13 May 2012 21:23:57 -0500 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On 5/13/12, William Herrin wrote: [snip] > Plan A: Debate, argue, maybe even analyze how significant or > insignificant a barrier we're talking about. > > Plan B: Remove the barrier. Look back later to see whether it had an > impact. I am in favor of B. Remove all barriers to IPv6 adoption that are easy to remove. Bureaucracy, application procedures, requirement for signatures, etc, are easy to remove. They didn't exist with IPv4 until there was an exhaustion problem. And they are an obstacle to IPv6 deployment whose impact is difficult or impossible to measure. It is justifiable to take a small chunk of IPv6 address space and do that. There are risks involved --- but in terms of risk measurement, exhaustion of IPv4 with little/no IPv6 deployment is a larger risk. > Regards, > Bill Herrin -- -JH From scottleibrand at gmail.com Sun May 13 22:30:43 2012 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sun, 13 May 2012 21:30:43 -0500 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On Sun, May 13, 2012 at 9:23 PM, Jimmy Hess wrote: > On 5/13/12, William Herrin wrote: > [snip] > > Plan A: Debate, argue, maybe even analyze how significant or > > insignificant a barrier we're talking about. > > > > Plan B: Remove the barrier. Look back later to see whether it had an > > impact. > > I am in favor of B. Remove all barriers to IPv6 adoption that are > easy to remove. > > Bureaucracy, application procedures, requirement for signatures, etc, > are easy to remove. They didn't exist with IPv4 until there was an > exhaustion problem. > > And they are an obstacle to IPv6 deployment whose impact is difficult > or impossible > to measure. > > It is justifiable to take a small chunk of IPv6 address space and do that. > There are risks involved --- but in terms of risk measurement, > exhaustion of IPv4 > with little/no IPv6 deployment is a larger risk. > Sounds like we have an idea for a concrete policy proposal here. I don't know if there is a lot of support for completely automatic IPv6 assignments (and I do know there are concerns about it), but it seems like something worth discussing at least. In addition, there may be an ACSP suggestion hiding in here (which I think has been made before) to create an "IPv6 Easy Button" to allow one-click assignment of an IPv6 block. It might be worth reviewing previous discussion on the topic ( https://encrypted.google.com/search?q=arin+ipv6+easy+button is a good place to start) and see if you can think of a way for ARIN to do it that doesn't run into the concerns expressed previously... And feel free to contact me if you want to bounce any ideas off someone before posting them publicly. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgrundemann at gmail.com Sun May 13 22:35:08 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sun, 13 May 2012 20:35:08 -0600 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On Sun, May 13, 2012 at 3:53 PM, Jimmy Hess wrote: Thanks for the reply Jimmy, some good points indeed - my responses are inline, below. > On 5/13/12, Chris Grundemann wrote: >> It's not a huge win because it won't make any appreciable difference, >> it's not actually a win at all. > > It removes a barrier in IPv6 deployment; ?which is not just about > cost, but also about time > and paperwork. Full agreement. Time and paperwork = cost; cost is a barrier... > It also greatly simplifies ?the allocation of > addresses, ?and therefore eliminates address space management overhead > expenses for the RIR. > Carve one /14 ?to represent /48 end-user assignments ?a priori based > on telephone number. > Carve one /8 to represent ?a IPv6 /24 end-user assignment ?for each > 16-bit AS number. > > Any allocation made in an unstructured way is then a "special allocation" Forcing folks who are unwilling to ask for IPv6 to decipher an algorithm, however simple the algorithm, is not simpler (for them) than assigning them a specific block of addresses directly (when they ask or them). Again, if they lack the motivation to apply for IPv6, what can lead us to believe that they will sit down and hash out their automatic assignment (of which they are very likely to be unaware)? >> Let's ask the real question here: How does blindly assigning IPv6 to >> organizations provide any additional motivation to deploy IPv6? If > > It takes away and excuse not to deploy IPv6. So noted. To make my stance more clear: If the only thing standing between orgX and IPv6 deployment is the cost of applying to ARIN for IPv6 space (time, paperwork and fees), then I have no confidence that automagically assigning space to orgX will actually cause them to deploy it. Yes, it makes it (marginally) easier to do so, but without any organizational motivation, it still will not happen. >> We could also revisit the formerly unpopular idea of requiring IPv6 >> deployment in order to obtain additional IPv4 addresses... > > Added barriers to deployment of IPv4 ?without IPv6 is also a possibility. > But based on your argument.... just obtaining the addresses doesn't > mean they will deploy IPV6. > > They may simply obtain IPv6 addresses, ?without deploying them, ?so that their > burden of obtaining more IPv4 resources is reduced. > > > Perhaps we should have a ?3 month ?SUPPLY ?rule on both allocations > and transfers > for organizations ?that have not demonstrated IPV6 deployment, > > A 12 months of IPv4 resources supply rule on allocations and transfers > to organizations > that have demonstrated at least 30% ?IPv6 deployment. Noting that this has been unpopular in the past, and that I (for the most part) agree with Mr. Dart that the implications of this may very well overstep our mandate of stewardship; there are many ways to determine deployment of IPv6 which are more substantial than simply 'we have received IPv6 addresses from an RIR.' Route announcement, DNS entries, IPv6 traffic levels, SWIP/WHOIS, configuration files, etc... This is absolutely do-able in a meaningful way, I think the question is rather whether or not the community feels comfortable doing it. Cheers, ~Chris > > -- > -JH -- @ChrisGrundemann http://chrisgrundemann.com From cgrundemann at gmail.com Sun May 13 22:41:15 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sun, 13 May 2012 20:41:15 -0600 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On Sun, May 13, 2012 at 7:33 PM, William Herrin wrote: > Plan A: Debate, argue, maybe even analyze how significant or > insignificant a barrier we're talking about. > > Plan B: Remove the barrier. Look back later to see whether it had an impact. I simply prefer to spend our limited time and policy cycles attempting the most effective and efficient methods of meeting the goals intended. Cheers, ~Chris > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 -- @ChrisGrundemann http://chrisgrundemann.com From mysidia at gmail.com Mon May 14 01:41:11 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 14 May 2012 00:41:11 -0500 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On 5/13/12, Chris Grundemann wrote: > On Sun, May 13, 2012 at 3:53 PM, Jimmy Hess wrote: >> On 5/13/12, Chris Grundemann wrote: > Forcing folks who are unwilling to ask for IPv6 to decipher an > algorithm, however simple the algorithm, is not simpler (for them) > than assigning them a specific block of addresses directly (when they > ask or them). Again, if they lack the motivation to apply for IPv6, [snip] That's an outreach problem. If the algorithm is simple enough; throw up a website, with a simple CGI program, to inform users of their allocation. eg (1) They enter their phone number in the form. Their auto IPv6 range is shown. With a HTTPS link to optionally set the reverse DNS mappings and whois contact, and a note that they can start using their allocation, and do this later, at any time. (But peers and upstreams may choose not to accept IPv6 address space until proper WHOIS listings are recorded) (2) Upon clicking the HTTPS link, they are prompted to enter their org handle or contact details and an e-mail address, they are notified of the nominal non-refundable fee, verification requirement, and annual maintenance cost, required to maintain the reverse DNS mappings and WHOIS listings. There is no application process, no manual verification required, the listing is simply confirmed by automated process. (3) They are prompted to setup a PIN number, and then click a "verification link". A robot will call the telephone number, and prompt them to enter the PIN number using the touch tone keypad. As soon as verification is completed, the WHOIS listing and reverse DNS server records are created, and the allocation is recognized. -- -JH From mysidia at gmail.com Mon May 14 01:59:02 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 14 May 2012 00:59:02 -0500 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On 5/13/12, Chris Grundemann wrote: > On Sun, May 13, 2012 at 7:33 PM, William Herrin wrote: [snip] > I simply prefer to spend our limited time and policy cycles attempting > the most effective and efficient methods of meeting the goals > intended. That makes sense. But only if you are proposing doing something different, that you can show is likely to be more effective. Also working on removing barriers to IPv6 deployment through automatic allocations is not mutually exclusive with other efficient means that may be more effective, does not detract from their effectiveness. ARIN can implement multiple changes and methods to encourage IPv6 deployment, that are more effective together, than any single change on its own. > Cheers, > ~Chris -- -JH From owen at delong.com Mon May 14 01:59:58 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 13 May 2012 22:59:58 -0700 Subject: [arin-ppml] ARIN Registration Agreements (was: ARIN-prop-170 Transfer of Number Resources in caseof Bankruptcy) In-Reply-To: <7F1ADA59-9DB9-4528-812B-69333C0497C3@corp.arin.net> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> <4FAC4ECE.2090205@gmx.com> <8695009A81378E48879980039EEDAD28012075D341@MAIL1.polartel.local> <489B906DB4054670A9F3017E7A7F4269@dp9100> <7F1ADA59-9DB9-4528-812B-69333C0497C3@corp.arin.net> Message-ID: <4C1E01B9-ADDF-417F-8E00-02265C7A82B6@delong.com> On May 13, 2012, at 11:05 AM, John Curran wrote: > On May 13, 2012, at 1:24 PM, Jimmy Hess wrote: > >> The agreements ARIN requires resource holders sign should solidify -- >> that the allocation and assignment of number resources do not convey >> any permanent ownership, do not confer any permanent or transferrable >> right or privilege to shared or exclusive use, do not confer any >> other rights that can be transferred, do not provide any rights that >> ARIN cannot revoke, that each allocation must be renewed every year >> with payment of fees, and ARIN may cancel any allocation, or >> refuse the renewal or transfer of any allocation. > > Jimmy - > > The registration services agreements are routinely updated and generally > go out for community consultation before any significant change. While > the current consultation periods are closed, please feel free to review > the RSA version 11 or LRSA version 3 agreements (they are very similar at > this point), and send any suggestions for changes to me for consideration > in future revisions. I'll think you will find much of your statements > above to be already in place. > As an alternative, you could also send the suggestions in via the ACSP process so that they are visibly documented for the community. This is not criticism of the idea of sending them to John directly. I am sure he will take them under advisement and pass them to the board in good faith, but, if you submit via ACSP, then other members of the community can also express support or opposition. Owen From drake.pallister at duraserver.com Mon May 14 00:52:14 2012 From: drake.pallister at duraserver.com (Drake Pallister) Date: Mon, 14 May 2012 00:52:14 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) References: <4F9E9E39.40501@brightok.net><5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net><39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru><68767A02-BBC6-43D2-B62F-947829343038@arin.net><4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost><4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost><20120513T020621Z@localhost> Message-ID: <737454EF49EC4F0CA57A4402C5BC452D@dp9100> Mr. Herrin, I don't have the answer, just more questions and some thoughts to ponder. How related do you think the widespread dragging of the feet about IPv6 is to the current economy? No matter what size an ORG is, they would need to roll out v6 in a size appropriate to their own size. Maybe it's not just the cost of procuring the v6's which gets smaller in proportion as the ORG gets bigger, but the other related things involved. Network equipment, servers, customer premises equipment, and lots of training-- both for the tech's and the semi-tech staff as in help desks people, & probablbly more factors too. The current economy isn't anything to be certain about, let alone future economy. Maybe there are companies thinking a glut of v4's will fall from the sky or that some arctic explorers will find a lost city of v4 slash 8's buried in the ice at the north pole. Some small or x-small v4 operations could use a xx-small v6 add-on allocation as a perk at renewal time to get them starting to play around with v6's and hopefully use them in operations. As far as direct-assigned end-users, I don't see any reason for them to desire to increase from their $100 per year maintenance fee to deploy v6 IPs as well as buy equipment and invest in training and reconfiguring. There's probably aso a comfort zone that some entities don't want to step out of, or perhaps don't even have the time to get involved with. For the v4 end users, I might think of the old saying, if it's not broken, what needs fixing. Trade-offs of v6 for v4 with other RIR's? That wouldn't help v6 encouragement here. Some countries are going hog wild with v6 yet others aren't. Back in 1972, USA needed a gasoline shortage to start considering smaller cars. Where did those smaller cars initially come from? Is there any correlation between those places and the places where IPv6 is taking off? Perhaps North Americans need to get their feet wet with v6. The multi-year v6 discount program didn't seem to spark enough interest or desire. V6 didn't seem to flow downhill from the biggies to the smalls. Maybe starting from the bottom with the small's by giving them some v6's upon annual renewal would spark their usage and the interest in v6 would flow uphill? A scenario within a small org might be something as follows: hey ARIN gave us some v6's, let's see how we can utilize them. A router here, a switch somewhere else, some customers over there, and they may take liking to v6. Hence, the phrase getting the feet wet without jumping all the way in. Just some thoughts. With all respect, Drake Pallister ----- Original Message ----- From: "William Herrin" To: "Chris Grundemann" Cc: "ARIN PPML" Sent: Sunday, May 13, 2012 9:33 PM Subject: Re: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) > On 5/13/12, Chris Grundemann wrote: >> On Sun, May 13, 2012 at 9:54 AM, William Herrin wrote: >>> If we gain speedier deployment and the potential loss is capped at a >>> single /14 of IPv6 address space, how is preemptive assignment not a >>> huge win? >> >> It's not a huge win because it won't make any appreciable difference, >> it's not actually a win at all. >> >> Let's ask the real question here: How does blindly assigning IPv6 to >> organizations provide any additional motivation to deploy IPv6? If >> today I don't think I need to deploy IPv6, and tomorrow I have an IPv6 >> block assigned to me out of the blue, how does that change my mind >> about deploying IPv6 in any way? > > I sit on a peering exchange at one of my sites. It's a layer-2 switch. > The only obstruction to peering on the exchange is that the exchange's > owner needs to assign IPv6 addresses. Which they don't presently have. > They're waiting for higher demand before doing the paperwork and > coughing up the cash. > > Nor is this situation unique. Two of my three networks have not done > anything with IPv6. IPv6 is so poorly used right now that I can't > justify the expense for the addresses to the customers. I could spend > the time as an idle priority project and it would get done. But I > can't spend the money. Not yet. Not until IPv6 is much more heavily > used. > > >> Yes reducing barriers lowers cost, but the barrier you are proposing >> to remove is a very low one, perhaps insignificant to the total cost >> of IPv6 deployment. What is likely more effective from an RIR >> perspective is adding motivation instead. > > Plan A: Debate, argue, maybe even analyze how significant or > insignificant a barrier we're talking about. > > Plan B: Remove the barrier. Look back later to see whether it had an > impact. > > 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 owen at delong.com Mon May 14 02:18:47 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 13 May 2012 23:18:47 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> On May 13, 2012, at 2:53 PM, Jimmy Hess wrote: > On 5/13/12, Chris Grundemann wrote: >> On Sun, May 13, 2012 at 9:54 AM, William Herrin wrote: >>> If we gain speedier deployment and the potential loss is capped at a >>> single /14 of IPv6 address space, how is preemptive assignment not a >>> huge win? >> It's not a huge win because it won't make any appreciable difference, >> it's not actually a win at all. > > It removes a barrier in IPv6 deployment; which is not just about > cost, but also about time > and paperwork. It also greatly simplifies the allocation of > addresses, and therefore eliminates address space management overhead > expenses for the RIR. > Carve one /14 to represent /48 end-user assignments a priori based > on telephone number. > Carve one /8 to represent a IPv6 /24 end-user assignment for each > 16-bit AS number. > > Any allocation made in an unstructured way is then a "special allocation" > Ick! I really don't want to have to renumber my IP network every time my telephone number changes. I don't know where you live, but, in the US, there is virtually no such thing as a "permanent" telephone number. > >> Let's ask the real question here: How does blindly assigning IPv6 to >> organizations provide any additional motivation to deploy IPv6? If > > It takes away and excuse not to deploy IPv6. It really doesn't. At least not a credible one. > >> We could also revisit the formerly unpopular idea of requiring IPv6 >> deployment in order to obtain additional IPv4 addresses... > > Added barriers to deployment of IPv4 without IPv6 is also a possibility. > But based on your argument.... just obtaining the addresses doesn't > mean they will deploy IPV6. > Right. Requiring them to get addresses does nothing. Requiring them to deploy, OTOH, might actually be meaningful. However, a large segment of the community believes that the RIRs should be protocol agnostic stewards of the resources. I happen to agree with them. Now, before you call me an IPv4 luddite, understand that I run a full dual-stack production network and hold the actual job title of IPv6 Evangelist and have helped a number of countries get added to the list of global IPv6 participants as well as a number of organizations throughout the world. I've conducted training programs on 6 continents. (If anyone needs IPv6 training in Antarctica and is willing to pay my travel expenses, I'll offer the class for free!) > They may simply obtain IPv6 addresses, without deploying them, so that their > burden of obtaining more IPv4 resources is reduced. Not if the requirement is deployment, not merely obtaining addresses. > > > Perhaps we should have a 3 month SUPPLY rule on both allocations > and transfers > for organizations that have not demonstrated IPV6 deployment, > > A 12 months of IPv4 resources supply rule on allocations and transfers > to organizations > that have demonstrated at least 30% IPv6 deployment. > I kind of like this one, but, it would not be protocol agnostic stewardship. Owen From owen at delong.com Mon May 14 02:23:24 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 13 May 2012 23:23:24 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On May 13, 2012, at 6:33 PM, William Herrin wrote: > On 5/13/12, Chris Grundemann wrote: >> On Sun, May 13, 2012 at 9:54 AM, William Herrin wrote: >>> If we gain speedier deployment and the potential loss is capped at a >>> single /14 of IPv6 address space, how is preemptive assignment not a >>> huge win? >> >> It's not a huge win because it won't make any appreciable difference, >> it's not actually a win at all. >> >> Let's ask the real question here: How does blindly assigning IPv6 to >> organizations provide any additional motivation to deploy IPv6? If >> today I don't think I need to deploy IPv6, and tomorrow I have an IPv6 >> block assigned to me out of the blue, how does that change my mind >> about deploying IPv6 in any way? > > I sit on a peering exchange at one of my sites. It's a layer-2 switch. > The only obstruction to peering on the exchange is that the exchange's > owner needs to assign IPv6 addresses. Which they don't presently have. > They're waiting for higher demand before doing the paperwork and > coughing up the cash. > > Nor is this situation unique. Two of my three networks have not done > anything with IPv6. IPv6 is so poorly used right now that I can't > justify the expense for the addresses to the customers. I could spend > the time as an idle priority project and it would get done. But I > can't spend the money. Not yet. Not until IPv6 is much more heavily > used. > > >> Yes reducing barriers lowers cost, but the barrier you are proposing >> to remove is a very low one, perhaps insignificant to the total cost >> of IPv6 deployment. What is likely more effective from an RIR >> perspective is adding motivation instead. > > Plan A: Debate, argue, maybe even analyze how significant or > insignificant a barrier we're talking about. > > Plan B: Remove the barrier. Look back later to see whether it had an impact. > The good news is that we already have actual data from this experiment being conducted in Asia. It led to much greater address distribution and virtually no increase in deployment. Owen From owen at delong.com Mon May 14 02:26:47 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 13 May 2012 23:26:47 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: <710C6411-4DBA-4F4E-A415-B186AD779F4E@delong.com> On May 13, 2012, at 7:23 PM, Jimmy Hess wrote: > On 5/13/12, William Herrin wrote: > [snip] >> Plan A: Debate, argue, maybe even analyze how significant or >> insignificant a barrier we're talking about. >> >> Plan B: Remove the barrier. Look back later to see whether it had an >> impact. > > I am in favor of B. Remove all barriers to IPv6 adoption that are > easy to remove. > > Bureaucracy, application procedures, requirement for signatures, etc, > are easy to remove. They didn't exist with IPv4 until there was an > exhaustion problem. This is not true. There have been application procedures dating back to when all allocations were issued by Jon Postel himself. Admittedly, they were somewhat less formal and had fewer steps earlier in the process than later, and, more steps and greater scrutiny has been added in reaction to the exhaustion problem, but, even when it was still InterNIC and there was no exhaustion problem, there were forms and application procedures that were necessary. The lack of required signatures created much of the difficulty we now have in draining the IPv4 swamp and reclaiming underutilized resources. I do not advocate repeating this mistake. > > And they are an obstacle to IPv6 deployment whose impact is difficult > or impossible > to measure. They really aren't. > > It is justifiable to take a small chunk of IPv6 address space and do that. > There are risks involved --- but in terms of risk measurement, > exhaustion of IPv4 > with little/no IPv6 deployment is a larger risk. It really isn't. It's only really a larger risk to those organizations that have chosen not to deploy IPv6 for whatever reason. At this point, I am comfortable with allowing them to suffer the consequences and costs of their (in)actions. Owen (Speaking only for myself and not in my role as an AC member) From izaac at setec.org Mon May 14 09:38:20 2012 From: izaac at setec.org (Izaac) Date: Mon, 14 May 2012 09:38:20 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T004128Z@localhost> Message-ID: <20120514T133004Z@localhost> On Sun, May 13, 2012 at 01:30:37PM -0500, Jimmy Hess wrote: > > their interest to do so on short order. How many more participants in > > IPv6 day do you think there would have been if address blocks were just > > laying around waiting to be deployed by excited network engineers? > > Hm... every 10-digit phone numther in the NANP can be represented using > 34 bits. And every IPv4 block is already represented 1-to-1 in 2002::/16. We don't need another goofy mechanism for automatic deployment. What we need is a mental shift on the part of applicants that they cannot simply kick the IPv6 deployment can down the road any longer. Requiring them to fill out the paperwork for a IPv6 allocation commensurate with their IPv4 allocation request would do this to at least some small extent by forcing them to think about it. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From cgrundemann at gmail.com Mon May 14 10:48:12 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 14 May 2012 08:48:12 -0600 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On Sun, May 13, 2012 at 11:59 PM, Jimmy Hess wrote: > On 5/13/12, Chris Grundemann wrote: > [snip] >> I simply prefer to spend our limited time and policy cycles attempting >> the most effective and efficient methods of meeting the goals >> intended. > > That makes sense. ? ?But only if you are proposing doing something > different, ?that you can show is ?likely to be more effective. You're right. Let me make my proposals more clear: 1) Make it as easy as possible for an org who actually wants IPv6 to get it. This is mostly in place today (allocation fee waivers, one maint. fee per Org ID, ease of qualification, etc.) but there is still some possible room for improvement: 1A) Waive IPv6 assignment fees for end-users who request both IPv4 and IPv6 simultaneously. 1B) Move the Also working on removing barriers to IPv6 deployment through automatic > allocations is not mutually exclusive ?with other efficient means that > may be more effective, ? does not detract from their effectiveness. Not strictly mutually exclusive, no. However, I believe that automatic assignments, however well intentioned, are not technically nor psychologically sound and run the risk of actually harming IPv6 deployment by making IPv6 addresses a gimmick, akin to cracker jack box toys. As we tighten the restrictions on IPv4 and loosen the qualifications for IPv6, we send a signal of value to the community. Is IPv6 value-less, to be thrown from parade floats like confetti? Or is it a valuable but abundant resource which requires both deployment and stewardship? > ARIN can implement multiple changes and methods to encourage IPv6 > deployment, ?that are more effective together, ?than any single change > on its own. You will find no disagreement on that from me. =) Cheers, ~Chris > -- > -JH -- @ChrisGrundemann http://chrisgrundemann.com From owen at delong.com Mon May 14 11:11:53 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 14 May 2012 08:11:53 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: <63F8F341-C238-491D-BB2A-8883D985BF01@delong.com> Sent from my iPad On May 14, 2012, at 7:48 AM, Chris Grundemann wrote: > On Sun, May 13, 2012 at 11:59 PM, Jimmy Hess wrote: >> On 5/13/12, Chris Grundemann wrote: >> [snip] >>> I simply prefer to spend our limited time and policy cycles attempting >>> the most effective and efficient methods of meeting the goals >>> intended. >> >> That makes sense. But only if you are proposing doing something >> different, that you can show is likely to be more effective. > > You're right. Let me make my proposals more clear: > > 1) Make it as easy as possible for an org who actually wants IPv6 to > get it. This is mostly in place today (allocation fee waivers, one > maint. fee per Org ID, ease of qualification, etc.) but there is still > some possible room for improvement: > 1A) Waive IPv6 assignment fees for end-users who request both IPv4 > and IPv6 simultaneously. I'm really not trying to be flip here, but, I am having some trouble parsing what you are suggesting... So let me see if I understand this correctly... You want to force me to consume more IPv4 in order to get my IPv6 for free? > 1B) Move the (both of these ideas likely need to move to ARIN discuss if they are > of interest and probably should go into the ASCP process if there is > support for either/both at this time) So instead of being able to get up to a /40 for $1,250, you want to limit that to a /48 and make the /40 or /44 cost more? Howe does that encourage IPv6 adoption, exactly? > 2) Provide additional motivation for orgs to request and deploy IPv6. > There are several top of mind methods to accomplish this: > 2A) Require the officer attestation to acknowledge the current > state of affairs regarding IPv4 exhaustion and IPv6 requirements. I actually like this. > 2B) Continue or even ramp up (especially targeting end users) ARINs > outreach efforts (which have been substantial in previous years but > are being wound down post IANA-exhaustion). They are winding down because we pretty much achieved audience saturation at the events that we participated in. If you have ideas for venues that could reach new audiences of end-users (or ISPs for that matter), I'm sure that ARIN would be very interested. I certainly am interested in any case. > 2C) Implement policy that requires IPv6 deployment. > (the first two again should probably move to ARIN discuss and be > submitted to the ASCP if they find support, the third has been > discussed and rejected before) Even though I am one of the biggest IPv6 cheerleaders on the planet, I believe this is a step away from protocol agnosticism that should be demonstrated by the RIRs. Leading a horse to water is one thing. This proposal would have us water-boarding the horse in an effort to get him to drink. > Since four of the five belong on ARIN discuss (and the fifth is likely > a non-starter), I will send a note there immediately following this > message to continue the conversation as others see fit. Thanks. > Nothing wrong with discussing them on arin-discuss (or even PPML, for that matter, IMHO). However, if you want action taken, better to submit them to ACSP. >> Also working on removing barriers to IPv6 deployment through automatic >> allocations is not mutually exclusive with other efficient means that >> may be more effective, does not detract from their effectiveness. > > Not strictly mutually exclusive, no. However, I believe that automatic > assignments, however well intentioned, are not technically nor > psychologically sound and run the risk of actually harming IPv6 > deployment by making IPv6 addresses a gimmick, akin to cracker jack > box toys. As we tighten the restrictions on IPv4 and loosen the > qualifications for IPv6, we send a signal of value to the community. > Is IPv6 value-less, to be thrown from parade floats like confetti? Or > is it a valuable but abundant resource which requires both deployment > and stewardship? +1 Owen From bill at herrin.us Mon May 14 11:16:27 2012 From: bill at herrin.us (William Herrin) Date: Mon, 14 May 2012 11:16:27 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On 5/14/12, Chris Grundemann wrote: > You're right. Let me make my proposals more clear: > > 1) Make it as easy as possible for an org who actually wants IPv6 to > get it. This is mostly in place today (allocation fee waivers, one > maint. fee per Org ID, ease of qualification, etc.) but there is still > some possible room for improvement: > 1A) Waive IPv6 assignment fees for end-users who request both IPv4 > and IPv6 simultaneously. This would be better than nothing however unless I'm badly mistaken, fewer than 10% of ARIN end-user assignees will request additional IPv4 addresses this year. > 1B) Move the (both of these ideas likely need to move to ARIN discuss if they are > of interest and probably should go into the ASCP process if there is > support for either/both at this time) It makes exactly no sense to discuss ideas for end-user assignments on a CLOSED discussion list to which very few end user assignees have access. Not if you want public access and public participation anyway. > 2) Provide additional motivation for orgs to request and deploy IPv6. > There are several top of mind methods to accomplish this: > 2A) Require the officer attestation to acknowledge the current > state of affairs regarding IPv4 exhaustion and IPv6 requirements. Eyeroll. > 2B) Continue or even ramp up (especially targeting end users) ARINs > outreach efforts (which have been substantial in previous years but > are being wound down post IANA-exhaustion). Stale. > 2C) Implement policy that requires IPv6 deployment. As pointed out in previous discussions, requiring deployment of one protocol or another would vastly expand ARIN's regulatory duties and may have legal pitfalls. 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 Mon May 14 11:35:52 2012 From: jcurran at arin.net (John Curran) Date: Mon, 14 May 2012 15:35:52 +0000 Subject: [arin-ppml] ARIN Registration Agreements (was: ARIN-prop-170 Transfer of Number Resources in caseof Bankruptcy) In-Reply-To: <4C1E01B9-ADDF-417F-8E00-02265C7A82B6@delong.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FAAD7B7.4050701@arin.net> <5E23819DB192BE43A083C3740C0EF7821FA8AFDA@S-ITSV-MBX01P.ead.ubc.ca> <4FAC4ECE.2090205@gmx.com> <8695009A81378E48879980039EEDAD28012075D341@MAIL1.polartel.local> <489B906DB4054670A9F3017E7A7F4269@dp9100> <7F1ADA59-9DB9-4528-812B-69333C0497C3@corp.arin.net> <4C1E01B9-ADDF-417F-8E00-02265C7A82B6@delong.com> Message-ID: On May 14, 2012, at 1:59 AM, Owen DeLong wrote: > > As an alternative, you could also send the suggestions in via the ACSP process > so that they are visibly documented for the community. > > This is not criticism of the idea of sending them to John directly. I am sure he > will take them under advisement and pass them to the board in good faith, but, > if you submit via ACSP, then other members of the community can also express > support or opposition. Indeed, that works as well. Normally, the comments received during community consultation are made publicly. I offered to accept anything additional you might have directly since we're not in a consultation over a new revision, but the suggestion process is also an available option. (For details, refer to: https://www.arin.net/participate/acsp/acsp.html) Thanks! /John John Curran President and CEO ARIN From cgrundemann at gmail.com Mon May 14 12:41:00 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 14 May 2012 10:41:00 -0600 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On Mon, May 14, 2012 at 9:16 AM, William Herrin wrote: > On 5/14/12, Chris Grundemann wrote: >> ? ?1B) Move the > Not following your logic here. How does nearly doubling the price of a > /47 encourage IPv6 deployment? Or did you mean move the boundary from > /40 to /39 so that /40's fall under x-small? My apologies. I blame an early morning bit-math (read addition & subtraction) mistake. I meant to go the other way; > (both of these ideas likely need to move to ARIN discuss if they are >> of interest and probably should go into the ASCP process if there is >> support for either/both at this time) > > It makes exactly no sense to discuss ideas for end-user assignments on > a CLOSED discussion list to which very few end user assignees have > access. Not if you want public access and public participation anyway. The ideas are simply not policy based. This being a policy mailing list I thought it best to point that out, and facilitate a move to the more appropriate list (which is open to all ARIN members, and to discussions of fees). Ultimately, if there is any support, I will submit the ideas to ASCP where everyone will have yet another chance to comment (in addition to any further comments, or eyerolls, folks make here). Cheers, ~Chris -- @ChrisGrundemann http://chrisgrundemann.com From izaac at setec.org Mon May 14 13:10:13 2012 From: izaac at setec.org (Izaac) Date: Mon, 14 May 2012 13:10:13 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <20120514T133004Z@localhost> References: <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T004128Z@localhost> <20120514T133004Z@localhost> Message-ID: <20120514T170909Z@localhost> On Mon, May 14, 2012 at 09:38:20AM -0400, Izaac wrote: > And every IPv4 block is already represented 1-to-1 in 2002::/16. We > don't need another goofy mechanism for automatic deployment. Err, "automatic allocation." A mechanism -- however goofy -- for "automatic deployment" would be the bees knees. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From bill at herrin.us Mon May 14 15:33:02 2012 From: bill at herrin.us (William Herrin) Date: Mon, 14 May 2012 15:33:02 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On 5/14/12, Chris Grundemann wrote: > On Mon, May 14, 2012 at 9:16 AM, William Herrin wrote: >> On 5/14/12, Chris Grundemann wrote: >>> (both of these ideas likely need to move to ARIN discuss if they are >>> of interest and probably should go into the ASCP process if there is >>> support for either/both at this time) >> >> It makes exactly no sense to discuss ideas for end-user assignments on >> a CLOSED discussion list to which very few end user assignees have >> access. Not if you want public access and public participation anyway. > > The ideas are simply not policy based. This being a policy mailing > list I thought it best to point that out, and facilitate a move to the > more appropriate list (which is open to all ARIN members, and to > discussions of fees). Hi Chris, ARIN members = ISPs plus a couple score other random folks. Is it your belief that it is "more appropriate" for only these individuals to engage in this discussion or offer input to the matter? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cgrundemann at gmail.com Mon May 14 15:42:43 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 14 May 2012 13:42:43 -0600 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: On Mon, May 14, 2012 at 1:33 PM, William Herrin wrote: > On 5/14/12, Chris Grundemann wrote: >> The ideas are simply not policy based. This being a policy mailing >> list I thought it best to point that out, and facilitate a move to the >> more appropriate list (which is open to all ARIN members, and to >> discussions of fees). > > Hi Chris, > > ARIN members = ISPs plus a couple score other random folks. Is it your > belief that it is "more appropriate" for only these individuals to > engage in this discussion or offer input to the matter? Hi Bill, I believe it is "most appropriate" to follow the defined scope of each mailing list: https://www.arin.net/participate/mailing_lists/index.html. If they are disagreeable to you, please feel free to make a suggestion through the ASCP. I will not stand in your way. It is my belief that all individuals who have an opinion should engage in this discussion and offer their input on the matter. I am doing everything in my power to do just that. Part of that duty, as I see it, is to avoid clogging mailing lists with off-topic conversation - of which this is becoming (or already is). I am happy to discuss all aspects of current and future policy with anyone who cares to chime in here on PPML. If you would like to continue this conversation of mailing list scope, I'll be happy to respond off-list - to allow more relevant conversations to continue unhindered here. Cheers, ~Chris > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 -- @ChrisGrundemann http://chrisgrundemann.com From mjoseph at google.com Mon May 14 16:13:16 2012 From: mjoseph at google.com (Mike Joseph) Date: Mon, 14 May 2012 13:13:16 -0700 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: Support. As I mentioned in Vancouver, I strongly urge the Board to take note of the progress of this proposal and implement it simultaneously with 2011-1. This proposal adds important safeguards to 2011-1 which is currently pending implementation. Thanks, Mike Joseph On Mon, Apr 30, 2012 at 10:18 AM, 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-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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon May 14 18:04:41 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 14 May 2012 17:04:41 -0500 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> Message-ID: <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> arin-consult may be an appropriate choice which is not limited to members. Then both of you might, perhaps be able to live with it? Owen Sent from my iPad On May 14, 2012, at 2:42 PM, Chris Grundemann wrote: > On Mon, May 14, 2012 at 1:33 PM, William Herrin wrote: >> On 5/14/12, Chris Grundemann wrote: > >>> The ideas are simply not policy based. This being a policy mailing >>> list I thought it best to point that out, and facilitate a move to the >>> more appropriate list (which is open to all ARIN members, and to >>> discussions of fees). >> >> Hi Chris, >> >> ARIN members = ISPs plus a couple score other random folks. Is it your >> belief that it is "more appropriate" for only these individuals to >> engage in this discussion or offer input to the matter? > > Hi Bill, > > I believe it is "most appropriate" to follow the defined scope of each > mailing list: https://www.arin.net/participate/mailing_lists/index.html. > If they are disagreeable to you, please feel free to make a suggestion > through the ASCP. I will not stand in your way. > > It is my belief that all individuals who have an opinion should engage > in this discussion and offer their input on the matter. I am doing > everything in my power to do just that. Part of that duty, as I see > it, is to avoid clogging mailing lists with off-topic conversation - > of which this is becoming (or already is). I am happy to discuss all > aspects of current and future policy with anyone who cares to chime in > here on PPML. If you would like to continue this conversation of > mailing list scope, I'll be happy to respond off-list - to allow more > relevant conversations to continue unhindered here. > > Cheers, > ~Chris > >> >> Regards, >> Bill Herrin >> >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 > > > > -- > @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. From bill at herrin.us Mon May 14 18:10:24 2012 From: bill at herrin.us (William Herrin) Date: Mon, 14 May 2012 18:10:24 -0400 Subject: [arin-ppml] [arin-discuss] Encouraging IPv6 Transition (From PPML) In-Reply-To: References: <20120514152739.a68f808d@concur.batblue.com> Message-ID: On 5/14/12, Bill Darte wrote: > What we need is a v6-only YouTube or other content segregation that allows > those with v6 to get a larger view of the worlds resources in some empathic > way. Hi Bill, For which valuable content are you willing to sacrifice 90+% of _your_ customer base between now and whenever folks sufficiently harass their ISPs to get online with IPv6? That's what I thought. 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 May 14 18:22:48 2012 From: bill at herrin.us (William Herrin) Date: Mon, 14 May 2012 18:22:48 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <737454EF49EC4F0CA57A4402C5BC452D@dp9100> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <737454EF49EC4F0CA57A4402C5BC452D@dp9100> Message-ID: On 5/14/12, Drake Pallister wrote: > I don't have the answer, just more questions and some thoughts to ponder. > How related do you think the widespread dragging of the feet about IPv6 is > to the current economy? Hi Drake, I think the major reasons for slow IPv6 deployment have nothing to do with the RIRs whatsoever and rest in areas over which the RIRs can exert no control. The economy is one drag for sure. Tight budgets mean no money for anything that isn't needed last week. Another major drag, is that the programmer's sockets API provides no clean, simple way to "connect to the first connectable of this list of IP addresses." As a result, only those applications whose programmers have gone to extraordinary measures will promptly fail over to the second IP address when the first is inaccessible. This isn't a problem in the normal state of IPv4 operations: most names map to only one address. Add IPv6 and that's no longer true: most names map to at least two addresses, one IPv6 and one IPv4. So, deploy IPv6 and suddenly your customers report problems reaching your server even though the IPv4 path is unchanged. These are not things ARIN can affect. What can ARIN do to encourage IPv6 deployment? Make the process of getting addresses cost and hassle free to the absolute maximum extent practical. 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 May 14 18:25:08 2012 From: bill at herrin.us (William Herrin) Date: Mon, 14 May 2012 18:25:08 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> Message-ID: On 5/14/12, Owen DeLong wrote: > arin-consult may be an appropriate choice which is not limited to members. Hi Owen, Arin-consult topics are initiated by ARIN. Should ARIN initiate a "How can we help you more rapidly deploy IPv6?" topic, I'll be pleased to engage in it there. 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 May 14 18:43:37 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 14 May 2012 17:43:37 -0500 Subject: [arin-ppml] [arin-discuss] Encouraging IPv6 Transition (From PPML) In-Reply-To: References: <20120514152739.a68f808d@concur.batblue.com> Message-ID: On 5/14/12, William Herrin wrote: > On 5/14/12, Bill Darte wrote: > Hi Bill, > For which valuable content are you willing to sacrifice 90+% of _your_ > customer base between now and whenever folks sufficiently harass their > ISPs to get online with IPv6? Hey... who knows... if you want to roll out a "limited access" beta of a new service, or a new feature on an existing service, that is not yet ready for 90% of the customer base, perhaps you could utilize requirement of IPv6 support as the means of limiting access. E.g. "New enhancements, service improvements, and additional features will be deployed as a technical preview accessible only to IPv6 users first". > That's what I thought. -- -JH From mysidia at gmail.com Mon May 14 22:22:01 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 14 May 2012 21:22:01 -0500 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> Message-ID: On 5/14/12, Owen DeLong wrote: [snip] > Ick! I really don't want to have to renumber my IP network every time my > telephone number changes. I don't know where you live, but, in the US, > there > is virtually no such thing as a "permanent" telephone number. Huh? Phone numbers are actually owned by the end customer, not the telco, as long as they maintain phone service, and they are therefore much more permanent than IP addresses. You actually own your phone number, you don't actually own IP addresses that you are assigned. A key difference: Phone numbers are even portable between providers and to/from local cell phone providers, as long as the end user org maintains phone service, you can't do the same with PA address assignments in IPv4 or IPv6. The ability to maintain permanent ownership is what makes the phone number a perfect identifier to leverage for IP address automatic assignment. The organization just needs to use some care, and make sure to pick a phone number, such as their 800#, they already have to indefinitely maintain for other business purposes. Businesses spend large amounts of advertising dollars publishing their phone numbers which are used by their customers, in advert material, directories, etc; it would be a pretty big disaster if their number "changed", as they would now be losing business. Organizations' contact numbers are not like your home phone number that you can change all the time without a big disadvantage. -- -JH From mysidia at gmail.com Mon May 14 22:39:01 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 14 May 2012 21:39:01 -0500 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> Message-ID: Telephone number is also not the only option, btw. The longest IPv4 prefix ARIN allocates is a /24. Another option is set aside a /8, under which every ARIN /24 IPv4 allocation is automatically mapped to a unique global unicast /32 IPv6 allocation; that is... under the /8, the assigned /24 IPv4 prefix bits are used to populate 24 bits in the IPv6 prefix. And if the ARIN IPv4 allocation happened to be a /20 instead, that would mean that the mapped space has an address size of /28. The disadvantage is it requires a prior address assignment from ARIN. And extra work to make sure an org id with multiple IPv4 allocations can only have one of them mapped at a time to an IPv6 allocation. On 5/14/12, Jimmy Hess wrote: > On 5/14/12, Owen DeLong wrote: > [snip] >> Ick! I really don't want to have to renumber my IP network every time my >> telephone number changes. I don't know where you live, but, in the US, >> there >> is virtually no such thing as a "permanent" telephone number. > > Huh? Phone numbers are actually owned by the end customer, not the > telco, as long as they maintain phone service, and they are therefore > much more permanent than IP addresses. You actually own your phone > number, you don't actually own IP addresses that you are assigned. > A key difference: Phone numbers are even portable between providers > and to/from local cell phone providers, as long as the end user org > maintains phone service, you can't do the same with PA address > assignments in IPv4 or IPv6. > > The ability to maintain permanent ownership is what makes the phone > number a perfect identifier to leverage for IP address automatic > assignment. The organization just needs to use some care, and make > sure to pick a phone number, such as their 800#, they already have to > indefinitely maintain for other business purposes. > > Businesses spend large amounts of advertising dollars publishing their > phone numbers which are used by their customers, in advert material, > directories, etc; it would be a pretty big disaster if their number > "changed", as they would now be losing business. > > Organizations' contact numbers are not like your home phone number > that you can change all the time without a big disadvantage. > > > -- > -JH > -- -Mysid From owen at delong.com Tue May 15 06:17:19 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 15 May 2012 03:17:19 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> Message-ID: On May 14, 2012, at 7:22 PM, Jimmy Hess wrote: > On 5/14/12, Owen DeLong wrote: > [snip] >> Ick! I really don't want to have to renumber my IP network every time my >> telephone number changes. I don't know where you live, but, in the US, >> there >> is virtually no such thing as a "permanent" telephone number. > > Huh? Phone numbers are actually owned by the end customer, not the > telco, as long as they maintain phone service, and they are therefore > much more permanent than IP addresses. You actually own your phone Huh? Where do you live? In the US, we have AREA code splits every once-in-a-while that result in people's numbers changing. Also, the creation of new COs sometimes results in a geographic area having its prefixes changed. Yes, these events are not super-regular, but, they're a royal pain when they do occur and adding network upheaval into that equation by mapping phone numbers to prefixes seems like a pretty bad idea. Also, if you move any significant distance, your phone number either changes, or, you end up paying substantial fees every month for a "foreign exchange prefix". > number, you don't actually own IP addresses that you are assigned. > A key difference: Phone numbers are even portable between providers > and to/from local cell phone providers, as long as the end user org > maintains phone service, you can't do the same with PA address > assignments in IPv4 or IPv6. You don't actually own phone numbers, either. They have greater (in some cases) portability than IP addresses, but, you don't actually own the number. > The ability to maintain permanent ownership is what makes the phone > number a perfect identifier to leverage for IP address automatic > assignment. The organization just needs to use some care, and make > sure to pick a phone number, such as their 800#, they already have to > indefinitely maintain for other business purposes. Were that ability not somewhat fictitious, I might even agree with you. However, since it doesn't actually pan out, the conclusions you draw from said assumption also don't completely pan out. > Businesses spend large amounts of advertising dollars publishing their > phone numbers which are used by their customers, in advert material, > directories, etc; it would be a pretty big disaster if their number > "changed", as they would now be losing business. Yep... Like I said, when they are forcibly changed, it's a major pain in the butt. > Organizations' contact numbers are not like your home phone number > that you can change all the time without a big disadvantage. I'm well aware of this. However, in both cases, they can and are sometimes changed at the instigation of the phone company and not the customer. Owen From info at arin.net Tue May 15 13:33:59 2012 From: info at arin.net (ARIN) Date: Tue, 15 May 2012 13:33:59 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - April 2012 In-Reply-To: <4F9EC94F.3090907@arin.net> References: <4F9EC94F.3090907@arin.net> Message-ID: <4FB29387.3030000@arin.net> > 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. The minutes from the ARIN Advisory Council's April 25 meeting have been published: https://www.arin.net/about_us/ac/ac2012_0425.html The deadline to begin a petition is 22 May 2012. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 4/30/12 1:18 PM, ARIN wrote: > 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 mcr at sandelman.ca Tue May 15 14:00:40 2012 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 15 May 2012 14:00:40 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> Message-ID: <13244.1337104840@marajade.sandelman.ca> >>>>> "William" == William Herrin writes: William> On 5/14/12, Owen DeLong wrote: >> arin-consult may be an appropriate choice which is not limited to >> members. William> Hi Owen, William> Arin-consult topics are initiated by ARIN. Should ARIN William> initiate a "How can we help you more rapidly deploy IPv6?" William> topic, I'll be pleased to engage in it there. And, who is "you" in this context. I think that ARIN is doing a great job getting *ISP*s to deploy IPv6. Enterprises and equipment and software vendors have different problems/requirements. And I'll say it again: enterprises and equipment vendors need Non-Connected Network space, and they need it at the same cost as RFC1918 address space. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From cgrundemann at gmail.com Tue May 15 14:32:39 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 15 May 2012 12:32:39 -0600 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <13244.1337104840@marajade.sandelman.ca> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> <13244.1337104840@marajade.sandelman.ca> Message-ID: On Tue, May 15, 2012 at 12:00 PM, Michael Richardson wrote: > >>>>>> "William" == William Herrin writes: > ? ?William> On 5/14/12, Owen DeLong wrote: > ? ?>> arin-consult may be an appropriate choice which is not limited to > ? ?>> members. > > ? ?William> Hi Owen, > > ? ?William> Arin-consult topics are initiated by ARIN. Should ARIN > ? ?William> initiate a "How can we help you more rapidly deploy IPv6?" > ? ?William> topic, I'll be pleased to engage in it there. > > And, who is "you" in this context. > I think that ARIN is doing a great job getting *ISP*s to deploy IPv6. > > Enterprises and equipment and software vendors have different > problems/requirements. > > And I'll say it again: enterprises and equipment vendors need > Non-Connected Network space, and they need it at the same cost as > RFC1918 address space. It's RFC 4193 space (ULA) for IPv6: https://tools.ietf.org/html/rfc4193. Or am I missing something? ~Chris > > -- > ] ? ? ? He who is tired of Weird Al is tired of life! ? ? ? ? ? | ?firewalls ?[ > ] ? Michael Richardson, Sandelman Software Works, Ottawa, ON ? ?|net architect[ > ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > ? Kyoto Plus: watch the video > ? ? ? ? ? ? ? ? ? ? ? then sign the petition. > _______________________________________________ > 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 bill at herrin.us Tue May 15 14:56:57 2012 From: bill at herrin.us (William Herrin) Date: Tue, 15 May 2012 14:56:57 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> <13244.1337104840@marajade.sandelman.ca> Message-ID: On 5/15/12, Chris Grundemann wrote: > On Tue, May 15, 2012 at 12:00 PM, Michael Richardson > wrote: >> And I'll say it again: enterprises and equipment vendors need >> Non-Connected Network space, and they need it at the same cost as >> RFC1918 address space. > > It's RFC 4193 space (ULA) for IPv6: > https://tools.ietf.org/html/rfc4193. Or am I missing something? Hi Chris, The math for statistical uniqueness in ULA, while internally correct, is based on some suspect assumptions. If you replace them with worst-case assumptions, the probability of collision when interconnecting two large organizations increases to something on the order of 1 in 1000. Maybe higher if you consider human factors as well. ULA Central or a similar RIR-managed ULA space might provide a better guarantee of uniqueness and would, for a certainty, make it easier to figure out who's "in the wrong" and must renumber when a collision occurs. It would also offer a user better control over what happens during data leak scenarios, e.g. RDNS requests which incorrectly make it to the Internet DNS servers. On the flip side, ULA is at it's very worst still far better than RFC1918. 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 Tue May 15 15:18:51 2012 From: bill at herrin.us (William Herrin) Date: Tue, 15 May 2012 15:18:51 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> Message-ID: On 5/14/12, Jimmy Hess wrote: > Telephone number is also not the only option, btw. The longest IPv4 > prefix ARIN allocates is a /24. > > Another option is set aside a /8, under which > every ARIN /24 IPv4 allocation is automatically mapped to a unique > global > unicast /32 IPv6 allocation; that is... under the /8, the > assigned /24 IPv4 prefix bits are used to populate 24 bits in the IPv6 > prefix. Hi Jimmy, One challenge with this sort of approach draws from NRPM 6.3.8: "In IPv6 address policy, the goal of aggregation is considered to be the most important." Let's stack the phone number approach against the goals: 6.3.2. Uniqueness: pass 6.3.3. Registration: assume they'll file paperwork with ARIN. Otherwise, fail. 6.3.4. Aggregation: very weak. All but the smallest orgs have many disjoint phone numbers. 6.3.5. Conservation: weak. Any unclaimed phone number is lost addresses. 6.3.6. Fairness: pass 6.3.7. Minimized Overhead: pass. Must still file paperwork with ARIN. 6.3.8. Conflict: fail. Aggregation goal is not prioritized. Compare to the preemptive assignment approach: 6.3.2. Uniqueness: pass 6.3.3. Registration: pass 6.3.4. Aggregation: pass 6.3.5. Conservation: weak. Some waste of addresses will occur here, though not especially worse than what occurs due to sparse allocation in general. 6.3.6. Fairness: potential long-term implications of IPv4 or AS holders getting IPv6 addresses automatically while anybody new has to pay. 6.3.7. Minimized Overhead: very strong. Bulk process based on a relatively simple database pull. 6.3.8. Conflict: pass. Priority on aggregation is maintained. Compare to "do nothing" and let the existing process play itself out: 6.3.2. Uniqueness: pass 6.3.3. Registration: pass 6.3.4. Aggregation: pass 6.3.5. Conservation: pass 6.3.6. Fairness: pass 6.3.7. Minimized Overhead: weak. Requires manual RIR analysis of request, payment. 6.3.8. Conflict: pass. Priority on aggregation is maintained. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From heather.skanks at gmail.com Tue May 15 16:30:27 2012 From: heather.skanks at gmail.com (Heather Schiller) Date: Tue, 15 May 2012 16:30:27 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> Message-ID: Sure, ARIN could pursue this type of recovery of ASN's - just like they could have pursued this kind of recovery for v4. The community rejected recovery several times, I think for the same reason they would reject recovery for ASN's. It simply does not address the underlying desire driving this policy: For the holder of the resource to choose (or have chosen for them, by a bankruptcy court) who to pass the resource on to. There is no underlying technical argument to do so, when a network, equipment or customers do not pass with the number resource, and those cases are covered by 8.2. I have yet to hear anyone describe a corner case not covered by 8.2, aside from the bankruptcy court trying to extract profit for a resource.. a resource that at other times we claim, derives its value solely from its uniqueness and the services provided by ARIN. So then, why do it? Because, in the case of ASN's where scarcity is not an issue, the specific order or length of the numbers means something to the receiver of the resource. Be they short, memorable, or have some interesting or historical provenance the receiver finds the specific ASN valuable. Unlike ASN's, v4 netblocks are becoming scarce, so folks are incentivized to reorder their affairs and free up resources. There is some reasonableness to that, and the idea of financially recovering what you can in order to cover the expense of renumbering. Will that be the case with ASN's or will the ASN's that get transferred already be vacant? The incentive to renumber needs to be high enough to justify or recover your renumbering costs. Which means that either there is profit to be made or the resource is unused. If its not in use, there is no expense for renumbering, so returning it back to the community is the right thing to do. It's like returning a book to the library.. I don't understand why the lender holding it should get to choose who gets to borrow it next. I believe thus far, no one has used 8.3 to transfer resources out of the goodness of their heart - those that believe the resources belong to the community have returned them to the free pool without regard to who will receive the resources in the future. --Heather On Wed, May 9, 2012 at 11:49 PM, Jimmy Hess wrote: > On 5/9/12, William Herrin wrote: >> On 5/9/12, John Curran wrote: >> For folks looking for a reason for AS number transfers, here's a thought: >> >> Implementing BGP communities is a nuisance with a 32-bit AS number. >> The convention is: 16 bits AS number, 16 bits tag. Virtually every > [snip] > > What you have shown is a good justification for obtaining a 16-bit AS > number. ? It's actually a valid justification, ? unlike other poor > excuses such as ?"a provider I want to peer with doesn't like 32bit > numbers" > > There are other solutions besides AS transfers that do not encourage > spammers to figure out which ASes are unused, ?and ?bulk mail WHOIS > contacts with solicitations to sell their ASN. > > > ARIN should assign 32-bit AS numbers to organizations that can use > 32-bit AS numbers, reserve ?16-bit AS numbers to organizations ?who > have a clear technical issue such as use of such communities; which > impacts their network implementation. ?16bit numbers should be > available to assign to orgs that have a reason such as that, ? ?and > for ARIN to make sure they are available requires that some of the > 16bit numbers ?not be available in the absence of a strong technical > reason such as that. > > > > It is not apparent that enabling ?specified transfers is the most > efficient way to reclaim AS numbers that are no longer in use, > however. > > Since there are only at most 8000 of them, in theory, ?and these AS > numbers are subject to RIR policy, ?there is not a massive swamp of > "Legacy AS numbers", ? I would suggest ?an alternate method of > reclaiming unused 16-bit AS numbers: > > > ARIN can compile a list of ?AS numbers ?that have been assigned more > than 90 days ago but do not appear as an Origin or Path member in > globally visible BGP prefix listings. ? ? ?ARIN can ?e-mail each > resource holder that has an AS number which does not appear, > requesting ? that the resource holder account for and show their usage > of the AS number resource ? or ?return it. > > The same should occur for a previously active AS number that > disappears from the table for more than 90 days. > > Responses showing a current private use of the AS number are not reclaimable. > Any returned AS numbers ?become part of the allocatable pool. > > AS numbers from which no adequate response is received with a > sufficient number of attempts to contact the AS number resource > holder, ?place the AS holder ?in a "Not in good standing" status, > the WHOIS Records for the AS go to ?"Resource not verified", > the matter must be resolved before allocating, or transferring any IP > address resources for the Org in or Out. > > > If the resource holder cannot be reached / does not respond to the > resource review request within 12 months, ?and the AS number still > does not appear in global tables, ?the AS assignment is revoked. > > > -- > -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 paul at redbarn.org Tue May 15 20:25:34 2012 From: paul at redbarn.org (paul vixie) Date: Wed, 16 May 2012 00:25:34 +0000 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: References: <4F9E9E39.40501@brightok.net> <20120513T020621Z@localhost> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> <13244.1337104840@marajade.sandelman.ca> Message-ID: <4FB2F3FE.9000604@redbarn.org> On 5/15/2012 6:32 PM, Chris Grundemann wrote: > On Tue, May 15, 2012 at 12:00 PM, Michael Richardson wrote: >> Enterprises and equipment and software vendors have different >> problems/requirements. >> >> And I'll say it again: enterprises and equipment vendors need >> Non-Connected Network space, and they need it at the same cost as >> RFC1918 address space. > It's RFC 4193 space (ULA) for IPv6: > https://tools.ietf.org/html/rfc4193. Or am I missing something? i don't know if you're "missing" these, but they come to mind. 1. RFC 4193 ULA space is statistically unique, not guaranteed unique. 2. RFC 3484 IPv6 address selection requirements make neighborhood mesh networking feasible. therefore it's not just enterprises and equipment vendors who may need something like this, and the definition of "connected" is no longer black and white. paul -- "I suspect I'm not known as a font of optimism." (VJS, 2012) From mysidia at gmail.com Tue May 15 20:41:06 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 15 May 2012 19:41:06 -0500 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: <4FB2F3FE.9000604@redbarn.org> References: <4F9E9E39.40501@brightok.net> <20120513T020621Z@localhost> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> <13244.1337104840@marajade.sandelman.ca> <4FB2F3FE.9000604@redbarn.org> Message-ID: On 5/15/12, paul vixie wrote: > i don't know if you're "missing" these, but they come to mind. > 1. RFC 4193 ULA space is statistically unique, not guaranteed unique. > 2. RFC 3484 IPv6 address selection requirements make neighborhood mesh If those RFCs can be revised so that they don't state the addresses are not to be used globally AND they can be revised so that IANA will provide registration with the WHOIS service of /48 ULA blocks in use for global unicast service, upon request. Then the ULA space would be a reasonable substitute for any action on ARIN's part to automatically assign /48s. It would not be a substitute for automatically mapping IPv4 assignments. A downside of ULA space is that all assignments are /48s Whereas, if ARIN mapped the bits of all IPv4 assignments onto a /8 ISPs that had received a /16 in IPv4, would have an automatic IPv6 /24 which is a more appropriate quantity of IPv6 resources for an ISP -- -JH From paul at redbarn.org Tue May 15 20:52:24 2012 From: paul at redbarn.org (paul vixie) Date: Wed, 16 May 2012 00:52:24 +0000 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: References: <4F9E9E39.40501@brightok.net> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> <13244.1337104840@marajade.sandelman.ca> <4FB2F3FE.9000604@redbarn.org> Message-ID: <4FB2FA48.6080804@redbarn.org> On 5/16/2012 12:41 AM, Jimmy Hess wrote: > On 5/15/12, paul vixie wrote: >> i don't know if you're "missing" these, but they come to mind. >> 1. RFC 4193 ULA space is statistically unique, not guaranteed unique. >> 2. RFC 3484 IPv6 address selection requirements make neighborhood mesh > If those RFCs can be revised so that [...lots of good ideas...] perhaps you'd be willing to pick up the pen on which i personally abandoned in 2007 or so? william herrin had sent me a long list of things that needed fixing. i'll be happy to send that list, and the nroff source code, to anyone who wants to restart it. > It would not be a substitute for automatically mapping IPv4 assignments. > A downside of ULA space is that all assignments are /48s > > Whereas, if ARIN mapped the bits of all IPv4 assignments onto a /8 > ISPs that had received a /16 in IPv4, would have an automatic IPv6 /24 > > which is a more appropriate quantity of IPv6 resources for an ISP i don't see why we'd base the long future of ipv6 on the short past of ipv4, or why current RIR policy fails to meet the needs of ISP's. so to me this problem seems unrelated to ULA. -- "I suspect I'm not known as a font of optimism." (VJS, 2012) From tvest at eyeconomics.com Wed May 16 01:35:58 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Wed, 16 May 2012 01:35:58 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> Message-ID: <737663A8-70F0-469A-AF0C-17C18E293CFC@eyeconomics.com> On May 9, 2012, at 8:30 PM, William Herrin wrote: > On 5/9/12, John Curran wrote: >>> ARIN-2012-3: ASN Transfers >> >> I was asked recently about the number of issued and not presently >> advertised ASN's in the ARIN region, and thought it best to reply >> publicly so everyone has the same information. >> >> ARIN does not directly monitor ASN usage, but the esteemed >> Geoff Huston does at >> >>> From that report as of this morning - >> >> There are 24406 16-bit ASN's assigned to the ARIN region, with >> 1099 presently in the regional free pool, 8259 unadvertised in >> BGP, and 15048 advertised in BGP. > > Interesting! > > For folks looking for a reason for AS number transfers, here's a thought: > > Implementing BGP communities is a nuisance with a 32-bit AS number. > The convention is: 16 bits AS number, 16 bits tag. Virtually every > shipping router is configured to display them in this manner. AS > numbers larger than 65535 require a service provider who wants to > offer communities to implement it in an unconventional manner. This > can be expected to cause collisions and other confusion in this > tagging mechanism for downstreams with more than one BGP link. Where > an organization wishes to implement communities, a 16-bit AS number is > *highly* desirable on a technical basis. > > Geoff's numbers suggest that there are upwards of 8,000 16-bit as > numbers recoverable in the ARIN region, some third of the total. Given > some incentive for the current holders to release them of course. When > we run out of fresh 16-bit AS numbers, the availability of those 8,000 > would simplify operations for new ISPs and new ISP efforts which use a > distinct AS number. > > Tom, is that a good enough reason to allow an AS number transfer? As a > technical necessity to follow the conventions for BGP communities? > > Regards, > Bill Herrin Hi Bill, Apologies for not responding to this question when you first posed it -- local distractions have been more numerous/pressing than usual, and I didn't want to respond before thinking about this a bit more. No surprise perhaps, but In the end I come to the same conclusion via the same logic that I applied to earlier transfer-related proposals. That is to say, I recognize that it is possible -- at least for a subset of a subset of current/incumbent operators in very narrow, specific operational circumstances -- to make a valid argument in favor of resource transfers as proposed based on the relative "technical" merits/convenience of the expected/best-possible results (i.e., the potential for some operators to buy/sell options to postpone or completely avoid the extra work vs. uncertainty tradeoffs associated with ASN32 BGP community interop, potentially until "everything gets sorted out" by someone else), assuming that all else remains equal. However, as with previous transfer proposals, I believe that the cons outweigh the pros by a wide margin. Or, to be more specific... Assuming that "all else remains equal" (i.e., no second-order, unintended effects): 1. The relative benefits that ASN transfers would provide as a response to this *specific* problem (i.e., as compared to non-transfer related alternatives), and the relatively modest size of the operator population to whom those benefits might be accessible, seem very very modest to me when compared to both (a) the lure of all of the other purely commercial/strategic ASN transfer-related aspirations that the community has already considered and rejected, and (b) the much larger population of current and future ARIN community members who are unlikely to ever use BGP communities externally, and who -- given the numerous and now unavoidable risks and uncertainties to come thanks to IPv4 exhaustion/IPv6 adaptation -- would almost certainly benefit more from maintaining something that more closely resembles the "status quo" in ASN-related policies. 2. The huge asymmetry in the relative duration(s) of impacts depending on whether this proposal is adopted or rejected. Assuming that the demand for ASN16 remains steady at appx. current rates, it seems quite likely that vendor code and/or other mechanisms for reducing the risk of ASN32 community collisions, etc. will become widely available in the not-too-distant future -- which means that 100% of the relative benefits to current extended community option users that you've highlighted will disappear in, at most, a couple of years. By contrast, the additional operational uncertainty and unpredictability that this policy would visit upon all ASN holders/BGP speakers and their customers -- not to mention the perverse incentives that this change would impose on the vastly larger number of operators, and non-operators, who likely would never have any (other) interest in BGP community options of any kind -- would go on forever, or at least for as long as BGP is widely used. To me, this seems like ample justification to oppose this proposed change. That said, if one is prepared to drop the artificial (and IMO, unrealistic) assumption that "all else would remain equal," then it seems to me that the argument against ASN transfers is even stronger. 1. Assuming that actual operational reliance on extended community options is more commonplace among large networks and transit providers than among than among smaller operators, the proposed rationale-policy would likely exacerbate the present pattern/trend toward ASN16 concentration, and thus shift us toward a future in which an ever-increasing share of those operators who possess the greatest capacity to contribute to an industry-wide "sorting out" of ASN32 issues choose instead to exercise the option that they purchased, in the form of ASN16 transfers, to just wait and let others work out the kinks. At best, this would likely push the achievement of rough ASN16-ASN32 technical and operational parity yet further into the indefinite future. 2. At worst, it might cause the ongoing, gradual narrowing over time of the perceived and actual feature gaps separating ASN16s from ASN32s to decelerate, or even to reverse course, multiply, and grow larger. The ultimate culmination of such a reversal would be the commercial rejection/non-viability of ASN32s, and the industry-wide "adverse selection" of perpetually scarce ASN16s. Conceivably, if credible evidence were to come to light indicating that current operational reliance on extended community options is uniform across operators of all sizes, then I might wish to reconsider my position. Alternately (per my message @May 4, 2012 5:29:20 PM EDT), if at some point in the future we learn that the preponderance of ASN16-based, extended community options-using operators have extended "most favored ASN format" treatment to their ASN32-based providers, peers and customers in all (other) operational matters, then I might temper or completely drop my objections at that point. Until such time, however, I am & will likely remain opposed. Regards, TV From owen at delong.com Wed May 16 06:11:20 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 16 May 2012 03:11:20 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> <13244.1337104840@marajade.sandelman.ca> Message-ID: On May 15, 2012, at 11:56 AM, William Herrin wrote: > On 5/15/12, Chris Grundemann wrote: >> On Tue, May 15, 2012 at 12:00 PM, Michael Richardson >> wrote: >>> And I'll say it again: enterprises and equipment vendors need >>> Non-Connected Network space, and they need it at the same cost as >>> RFC1918 address space. >> >> It's RFC 4193 space (ULA) for IPv6: >> https://tools.ietf.org/html/rfc4193. Or am I missing something? > > Hi Chris, > > The math for statistical uniqueness in ULA, while internally correct, > is based on some suspect assumptions. If you replace them with > worst-case assumptions, the probability of collision when > interconnecting two large organizations increases to something on the > order of 1 in 1000. Maybe higher if you consider human factors as > well. So what... He said he wanted equivalent functionality to RFC-1918 where your risk of collision is more like 1 in 3 at best and usually 1 in 1 in my experience. > ULA Central or a similar RIR-managed ULA space might provide a better > guarantee of uniqueness and would, for a certainty, make it easier to > figure out who's "in the wrong" and must renumber when a collision > occurs. It would also offer a user better control over what happens > during data leak scenarios, e.g. RDNS requests which incorrectly make > it to the Internet DNS servers. It would also become GUA in short order. > On the flip side, ULA is at it's very worst still far better than RFC1918. Exactly. It's still a bad idea, but, it's a less bad idea than RFC-1918 was and not nearly as misguided as ULA-global. Owen From owen at delong.com Wed May 16 06:14:44 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 16 May 2012 03:14:44 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> Message-ID: <685CEFF2-D15F-4878-8677-9A3CC7EFB951@delong.com> On May 15, 2012, at 12:18 PM, William Herrin wrote: > On 5/14/12, Jimmy Hess wrote: >> Telephone number is also not the only option, btw. The longest IPv4 >> prefix ARIN allocates is a /24. >> >> Another option is set aside a /8, under which >> every ARIN /24 IPv4 allocation is automatically mapped to a unique >> global >> unicast /32 IPv6 allocation; that is... under the /8, the >> assigned /24 IPv4 prefix bits are used to populate 24 bits in the IPv6 >> prefix. > > Hi Jimmy, > > One challenge with this sort of approach draws from NRPM 6.3.8: "In > IPv6 address policy, the goal of aggregation is considered to be the > most important." > > Let's stack the phone number approach against the goals: > > 6.3.2. Uniqueness: pass > 6.3.3. Registration: assume they'll file paperwork with ARIN. Otherwise, fail. > 6.3.4. Aggregation: very weak. All but the smallest orgs have many > disjoint phone numbers. > 6.3.5. Conservation: weak. Any unclaimed phone number is lost addresses. > 6.3.6. Fairness: pass > 6.3.7. Minimized Overhead: pass. Must still file paperwork with ARIN. > 6.3.8. Conflict: fail. Aggregation goal is not prioritized. > > > Compare to the preemptive assignment approach: > > 6.3.2. Uniqueness: pass > 6.3.3. Registration: pass > 6.3.4. Aggregation: pass > 6.3.5. Conservation: weak. Some waste of addresses will occur here, > though not especially worse than what occurs due to sparse allocation > in general. > 6.3.6. Fairness: potential long-term implications of IPv4 or AS > holders getting IPv6 addresses automatically while anybody new has to > pay. > 6.3.7. Minimized Overhead: very strong. Bulk process based on a > relatively simple database pull. > 6.3.8. Conflict: pass. Priority on aggregation is maintained. Er... I think that should read: 6.3.8 Conflict: fail: Aggregation is degraded to to probability of improperly sized allocations > Compare to "do nothing" and let the existing process play itself out: > > 6.3.2. Uniqueness: pass > 6.3.3. Registration: pass > 6.3.4. Aggregation: pass > 6.3.5. Conservation: pass > 6.3.6. Fairness: pass > 6.3.7. Minimized Overhead: weak. Requires manual RIR analysis of > request, payment. > 6.3.8. Conflict: pass. Priority on aggregation is maintained. Looks to me like the current process is the best of the three even without the above correction to your analysis. Owen From owen at delong.com Wed May 16 06:21:21 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 16 May 2012 03:21:21 -0700 Subject: [arin-ppml] Further opposition to 2012-3 Message-ID: In addition to the arguments already stated, I believe that 2012-3 is detrimental and not technically sound policy in the following way: It will continue to promote the (unique to the ARIN region) perception that 32-bit ASNs are not usable and create an artificial value and resulting market in ASNs where the first 16 bits are zero. This could further delay implementation of 32-bit ASN support in our region and create an unfair disadvantage for organizations that cannot obtain ASNs with the high-order 16 bits set to zero other than through the transfer market. As such, I remain strenuously opposed to this draft policy being forwarded to the board for adoption. Owen From dogwallah at gmail.com Wed May 16 08:01:44 2012 From: dogwallah at gmail.com (McTim) Date: Wed, 16 May 2012 08:01:44 -0400 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: <737663A8-70F0-469A-AF0C-17C18E293CFC@eyeconomics.com> References: <4F9EC985.1030503@arin.net> <737663A8-70F0-469A-AF0C-17C18E293CFC@eyeconomics.com> Message-ID: On Wed, May 16, 2012 at 1:35 AM, Tom Vest wrote: > > On May 9, 2012, at 8:30 PM, William Herrin wrote: > >> On 5/9/12, John Curran wrote: >>>> ARIN-2012-3: ASN Transfers >>> >>> I was asked recently about the number of issued and not presently >>> advertised ASN's in the ARIN region, and thought it best to reply >>> publicly so everyone has the same information. >>> >>> ARIN does not directly monitor ASN usage, but the esteemed >>> Geoff Huston does at >>> >>>> From that report as of this morning - >>> >>> ? There are 24406 16-bit ASN's assigned to the ARIN region, with >>> ? 1099 presently in the regional free pool, 8259 unadvertised in >>> ? BGP, and 15048 advertised in BGP. >> >> Interesting! >> >> For folks looking for a reason for AS number transfers, here's a thought: >> >> Implementing BGP communities is a nuisance with a 32-bit AS number. >> The convention is: 16 bits AS number, 16 bits tag. Virtually every >> shipping router is configured to display them in this manner. AS >> numbers larger than 65535 require a service provider who wants to >> offer communities to implement it in an unconventional manner. This >> can be expected to cause collisions and other confusion in this >> tagging mechanism for downstreams with more than one BGP link. Where >> an organization wishes to implement communities, a 16-bit AS number is >> *highly* desirable on a technical basis. >> >> Geoff's numbers suggest that there are upwards of 8,000 16-bit as >> numbers recoverable in the ARIN region, some third of the total. Given >> some incentive for the current holders to release them of course. When >> we run out of fresh 16-bit AS numbers, the availability of those 8,000 >> would simplify operations for new ISPs and new ISP efforts which use a >> distinct AS number. >> >> Tom, is that a good enough reason to allow an AS number transfer? As a >> technical necessity to follow the conventions for BGP communities? >> >> Regards, >> Bill Herrin > > > Hi Bill, > > Apologies for not responding to this question when you first posed it -- local distractions have been more numerous/pressing than usual, and I didn't want to respond before thinking about this a bit more. > > No surprise perhaps, but In the end I come to the same conclusion via the same logic that I applied to earlier transfer-related proposals. That is to say, I recognize that it is possible -- at least for a subset of a subset of current/incumbent operators in very narrow, specific operational circumstances -- to make a valid argument in favor of resource transfers as proposed based on the relative "technical" merits/convenience of the expected/best-possible results (i.e., the potential for some operators to buy/sell options to postpone or completely avoid the extra work vs. uncertainty tradeoffs associated with ASN32 BGP community interop, potentially until "everything gets sorted out" by someone else), assuming that all else remains equal. ?However, as with previous transfer proposals, I believe that the cons outweigh the pros by a wide margin. Or, to be more specific... > > Assuming that "all else remains equal" (i.e., no second-order, unintended effects): > > 1. The relative benefits that ASN transfers would provide as a response to this *specific* problem (i.e., as compared to non-transfer related alternatives), and the relatively modest size of the operator population to whom those benefits might be accessible, seem very very modest to me when compared to both (a) the lure of all of the other purely commercial/strategic ASN transfer-related aspirations that the community has already considered and rejected, and (b) the much larger population of current and future ARIN community members who are unlikely to ever use BGP communities externally, and who -- given the numerous and now unavoidable risks and uncertainties to come thanks to IPv4 exhaustion/IPv6 adaptation -- would almost certainly benefit more from maintaining something that more closely resembles the "status quo" in ASN-related policies. +1 I am also opposed to 2012-3 > > 2. The huge asymmetry in the relative duration(s) of impacts depending on whether this proposal is adopted or rejected. Assuming that the demand for ASN16 remains steady at appx. current rates, it seems quite likely that vendor code and/or other mechanisms for reducing the risk of ASN32 community collisions, etc. will become widely available in the not-too-distant future -- which means that 100% of the relative benefits to current extended community option users that you've highlighted will disappear in, at most, a couple of years. By contrast, the additional operational uncertainty and unpredictability that this policy would visit upon all ASN holders/BGP speakers and their customers -- not to mention the perverse incentives that this change would impose on the vastly larger number of operators, and non-operators, who likely would never have any (other) interest in BGP community options of any kind -- would go on forever, or at least for as long as BGP is widely used. > > To me, this seems like ample justification to oppose this proposed change. Agreed. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From bill at herrin.us Wed May 16 08:34:48 2012 From: bill at herrin.us (William Herrin) Date: Wed, 16 May 2012 08:34:48 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <685CEFF2-D15F-4878-8677-9A3CC7EFB951@delong.com> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <685CEFF2-D15F-4878-8677-9A3CC7EFB951@delong.com> Message-ID: On 5/16/12, Owen DeLong wrote: > On May 15, 2012, at 12:18 PM, William Herrin wrote: >> Compare to the preemptive assignment approach: >> >> 6.3.2. Uniqueness: pass >> 6.3.3. Registration: pass >> 6.3.4. Aggregation: pass >> 6.3.5. Conservation: weak. Some waste of addresses will occur here, >> though not especially worse than what occurs due to sparse allocation >> in general. >> 6.3.6. Fairness: potential long-term implications of IPv4 or AS >> holders getting IPv6 addresses automatically while anybody new has to >> pay. >> 6.3.7. Minimized Overhead: very strong. Bulk process based on a >> relatively simple database pull. >> 6.3.8. Conflict: pass. Priority on aggregation is maintained. > > Er... I think that should read: > 6.3.8 Conflict: fail: Aggregation is degraded to to probability of > improperly sized allocations Hi Owen, Given: 1. Recent discussions about the need to loosen subsequent allocation rules due to commonplace errors in initial IPv6 allocation choices with the existing process, 2. Sparse allocation intended to allow modest resizing without creating disjoint assignments, and 3. The recipient's ability to turn in the assignment when requesting a replacement should it be evident in an up-front manner that the assignment is not the right size The foundation for a claim that preemptive assignment meaningfully harms aggregation is most weak. > Looks to me like the current process is the best of the three even without > the above correction to your analysis. Until you throw in the missing goal, the one we're discussing in this thread: Until IPv6 use is ubiquitous, barriers to acquiring technically needful IPv6 address assignments should be minimized to the maximum extent practical. Personally, I'd rank that goal second only to aggregation. Certainly it's far more important than 6.3.5: conservation. ARIN policy on IPv6 assignment presents far fewer barriers than it did four years ago, but reasonable analysis grades any resource request from ARIN as "difficult." For IPv4, that's as it should be. Conservation is IPv4's leading goal, so there is supposed to be major back pressure to careless consumption. For IPv6, it's a needless barrier to adoption. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Wed May 16 08:55:58 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 16 May 2012 05:55:58 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <685CEFF2-D15! F-4878-8677-9A3CC7EFB951@delong.com> Message-ID: <553FA40D-F426-400E-9542-454FB11C7FF4@delong.com> On May 16, 2012, at 5:34 AM, William Herrin wrote: > On 5/16/12, Owen DeLong wrote: >> On May 15, 2012, at 12:18 PM, William Herrin wrote: >>> Compare to the preemptive assignment approach: >>> >>> 6.3.2. Uniqueness: pass >>> 6.3.3. Registration: pass >>> 6.3.4. Aggregation: pass >>> 6.3.5. Conservation: weak. Some waste of addresses will occur here, >>> though not especially worse than what occurs due to sparse allocation >>> in general. >>> 6.3.6. Fairness: potential long-term implications of IPv4 or AS >>> holders getting IPv6 addresses automatically while anybody new has to >>> pay. >>> 6.3.7. Minimized Overhead: very strong. Bulk process based on a >>> relatively simple database pull. >>> 6.3.8. Conflict: pass. Priority on aggregation is maintained. >> >> Er... I think that should read: >> 6.3.8 Conflict: fail: Aggregation is degraded to to probability of >> improperly sized allocations > > Hi Owen, > > Given: > > 1. Recent discussions about the need to loosen subsequent allocation > rules due to commonplace errors in initial IPv6 allocation choices > with the existing process, > 2. Sparse allocation intended to allow modest resizing without > creating disjoint assignments, and > 3. The recipient's ability to turn in the assignment when requesting a > replacement should it be evident in an up-front manner that the > assignment is not the right size > > The foundation for a claim that preemptive assignment meaningfully > harms aggregation is most weak. > We can agree to disagree about this. > >> Looks to me like the current process is the best of the three even without >> the above correction to your analysis. > > Until you throw in the missing goal, the one we're discussing in this > thread: Until IPv6 use is ubiquitous, barriers to acquiring > technically needful IPv6 address assignments should be minimized to > the maximum extent practical. Personally, I'd rank that goal second > only to aggregation. Certainly it's far more important than 6.3.5: > conservation. To some extent, I agree with you. However, I don't believe that preemptive assignments remove barriers so much as create an illusory consumption. As such, I would argue that preemptive assignments fall somewhere between weak and fail in that particular goal. > ARIN policy on IPv6 assignment presents far fewer barriers than it did > four years ago, but reasonable analysis grades any resource request > from ARIN as "difficult." For IPv4, that's as it should be. > Conservation is IPv4's leading goal, so there is supposed to be major > back pressure to careless consumption. For IPv6, it's a needless > barrier to adoption. I disagree. It took me less than an hour to prepare HE's subsequent allocation request for ARIN and submit it. It took less than 48 hours for ARIN to issue the requested /24. When I got my /48 for my own end-site, it was as simple as filling out the template with a statement of "I have PI IPv4, please give me a /48". It took ARIN less than 3 days to approve my request and issue my addresses. I've done multiple IPv6 end-user and ISP requests for various clients. None of them were what I would call difficult on the ARIN side. The largest difficulties are usually explaining ARIN policy and the limitations thereof to the clients and this is primarily a problem for IPv4. The second hardest part is dealing with the client's poor record keeping in determining how to justify an appropriate request to ARIN. While pre-emptive assignments/allocations MAY work around those issues, I would argue that working around those issues rather than resolving them is NOT a desired outcome. Owen From jcurran at arin.net Wed May 16 09:31:37 2012 From: jcurran at arin.net (John Curran) Date: Wed, 16 May 2012 13:31:37 +0000 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <685CEFF2-D15F-4878-8677-9A3CC7EFB951@delong.com> Message-ID: <1AC3C08D-2754-4ED3-888A-DD761C0E511A@corp.arin.net> On May 16, 2012, at 8:34 AM, William Herrin wrote: > The foundation for a claim that preemptive assignment meaningfully > harms aggregation is most weak. Routing aggregation from preemptive provider-independent assignments will definitely be much, much less than provider-assigned IPv6 prefixes, and while there is some chance of aggregation of successive assignments, it is likely that there are very few such end-user successive assignments to actually make a meaningful difference. If indeed the community feels that provider-based IPv6 aggregation is unnecessary (I truly do no know either way and believe that those who operate large numbers of DFZ routers need to weigh in here), then there are actually easier approaches to the problem which provide for fully automatic IPv6 end-user block assignment. For example, a single /16 global reservation done for the purposes of providing algorithmic assignment via concatenation of AS number would mean any party with an AS # would also have an associated /48 IPv6 block. There is nominal administrative aggregation at the RIR level for things like reverse DNS in such a model, but realistically no aggregation in the IPv6 routing announcements would result from this approach. Other aggregation-free approaches to consider include IPv4 address concatenation to a global prefix, prefix + MEID, etc. The IETF has historically not supported such approaches (citing the very poor routing aggregation properties of provider-independent end-user assignments and concerns from the ops community from widespread use) but if circumstances have changed, then revisiting these approaches could provide some very straightforward models for widespread IPv6 number resource availability. FYI, /John John Curran President and CEO ARIN From bill at herrin.us Wed May 16 10:47:24 2012 From: bill at herrin.us (William Herrin) Date: Wed, 16 May 2012 10:47:24 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <553FA40D-F426-400E-9542-454FB11C7FF4@delong.com> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <553FA40D-F426-400E-9542-454FB11C7FF4@delong.com> Message-ID: On 5/16/12, Owen DeLong wrote: > On May 16, 2012, at 5:34 AM, William Herrin wrote: >> On 5/16/12, Owen DeLong wrote: >>> Looks to me like the current process is the best of the three even >>> without >>> the above correction to your analysis. >> >> Until you throw in the missing goal, the one we're discussing in this >> thread: Until IPv6 use is ubiquitous, barriers to acquiring >> technically needful IPv6 address assignments should be minimized to >> the maximum extent practical. > > To some extent, I agree with you. However, I don't believe that preemptive > assignments remove barriers so much as create an illusory consumption. I think that's a fair difference of opinion. Short of trying it, I don't know that it's possible to prove it one way or another. >> ARIN policy on IPv6 assignment presents far fewer barriers than it did >> four years ago, but reasonable analysis grades any resource request >> from ARIN as "difficult." > > I disagree. It took me less than an hour to prepare HE's subsequent > allocation request for ARIN and submit it. It took less than 48 hours > for ARIN to issue the requested /24. You're a subject matter expert, as am I. Try it as someone who is still learning IPv6 and has no knowledge of ARIN's deep mysteries. Folks who don't have an IP address management specialist on staff often contract someone each time they interact with ARIN or get one of their ISP's specialists to help. Like hiring a lawyer to represent you in court. You don't do that until your goal becomes a priority. For the vast majority of organizations, IPv6 deployment is not a high priority and it's not likely to become a high priority any time soon. You mean if I and everybody else rush to deploy IPv6 then I might not have to worry about IP addresses ten years from now? Hrm. Folks will fiddle with IPv6 out of curiosity and as part of the routine effort to keep one's skills current. But such idle priority tasks don't get high priority resources. Which means no consultants and no major fees. Which means no address request to ARIN. Which means zero idle-priority deployment of IPv6 for multihomed orgs. Which in most cases is the only form of IPv6 deployment that can reasonably be expected at this stage. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Wed May 16 11:01:12 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 16 May 2012 08:01:12 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <553FA40D-F426-400E-9542-454FB11C7FF4@delong.com> Message-ID: >>> ARIN policy on IPv6 assignment presents far fewer barriers than it did >>> four years ago, but reasonable analysis grades any resource request >>> from ARIN as "difficult." >> >> I disagree. It took me less than an hour to prepare HE's subsequent >> allocation request for ARIN and submit it. It took less than 48 hours >> for ARIN to issue the requested /24. > > You're a subject matter expert, as am I. Try it as someone who is > still learning IPv6 and has no knowledge of ARIN's deep mysteries. > Sorry, I'm not willing to buy this argument when discussing an organization that already has an IPv4 assignment from ARIN. Somewhere in the organization's past, someone already went through the IPv4 process. If they're going back for an additional assignment (as was described in the proposal), then, someone is going to have to learn all of that to navigate the IPv4 process anyway. IPv6 is the exact same process except that the template is much simpler and your justification section can be as simple as: I have N buildings on O campuses. The largest campus has Q buildings. Please give me R /48s. (it's not particularly complicated to compute the values of N, O, Q, and R for any organization). > Folks who don't have an IP address management specialist on staff > often contract someone each time they interact with ARIN or get one of > their ISP's specialists to help. Like hiring a lawyer to represent you > in court. You don't do that until your goal becomes a priority. When any of my customers engage me to help them get an IPv4 assignment, I urge them to consider also doing an IPv6 assignment at the same time. I am often able to do this without adding hours to the contract as the data required is already in the IPv4 process in most cases. This often leads to additional hours of IPv6 consulting for said customer, so, any consultant that is doing IPv4 applications for end-users and not selling IPv6 as an add-on is missing business opportunities. > For the vast majority of organizations, IPv6 deployment is not a high > priority and it's not likely to become a high priority any time soon. > You mean if I and everybody else rush to deploy IPv6 then I might not > have to worry about IP addresses ten years from now? Hrm. Sure, but, those organizations that might benefit from this proposed auto-assignment of IPv6 are coming back for additional IPv4 anyway, so, any rational consultant would be looking to add IPv6 as an inexpensive upsell that may leverage additional consulting business later. > Folks will fiddle with IPv6 out of curiosity and as part of the > routine effort to keep one's skills current. But such idle priority > tasks don't get high priority resources. Which means no consultants > and no major fees. Which means no address request to ARIN. Which means > zero idle-priority deployment of IPv6 for multihomed orgs. Which in > most cases is the only form of IPv6 deployment that can reasonably be > expected at this stage. Sure, but, if they're doing IPv4 anyway, they can get an IPv6 added without paying much more, if any, to the consultant. Owen From mcr at sandelman.ca Wed May 16 11:11:16 2012 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 16 May 2012 11:11:16 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> <13244.1337104840@marajade.sandelman.ca> Message-ID: <26873.1337181076@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Owen" == Owen DeLong writes: >> The math for statistical uniqueness in ULA, while internally >> correct, is based on some suspect assumptions. If you replace >> them with worst-case assumptions, the probability of collision >> when interconnecting two large organizations increases to >> something on the order of 1 in 1000. Maybe higher if you consider >> human factors as well. Owen> So what... He said he wanted equivalent functionality to Owen> RFC-1918 where your risk of collision is more like 1 in 3 at Owen> best and usually 1 in 1 in my experience. RFC1918 risk of collision is the reason to argue for IPv6 in the first place. I work for one company that decided that squatting on 2.0.0.0/8 for their chassis communications was better than conflicting with RFC1918. But, I didn't say it was risk of collision with ULA-R that was the main problem, it is lack of reverse DNS and lack of whois that is the problem. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBT7PDkoCLcPvd0N1lAQKK2Qf/SoHMCFZ9Xls0xX/aGLkhL7LecTHPfwmP jQxUvuxWooSAq4yaFnFck+rzB3mE2aCX89H/4jJ5IaThdHwjR3oJ/f+gLSDvEyub ipZTWCpxPHZbG+kE1DZpdpw04ZXfSRpR+w3eibjTXA8mTQOWBwNuRfP2QyLyhNxG lbz5Au4Hz0vXzmHrsFkXwfuM4kOC84oYw2S16wNIAB2HHM8/S5MjNrwuosic6aJI UsUjRg0B5tbVprLBWNvRQT7WRlp7UUVk7c4tqyy+MTuZxAxf/wzWYOS9335HsSuv f/BvFrrrNvUAByd60dlIHcO+iC0FB4B/RPALagr2EwWfvSP5FpvfkQ== =/K3Z -----END PGP SIGNATURE----- From owen at delong.com Wed May 16 11:24:42 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 16 May 2012 08:24:42 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <26873.1337181076@marajade.sandelman.ca> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> <13244.1337104840@marajade.sandelman.ca> <26873.1337181076@marajade.sandelman.ca> Message-ID: <504AB22C-864B-4BAC-9928-67E671E78FE2@delong.com> On May 16, 2012, at 8:11 AM, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "Owen" == Owen DeLong writes: >>> The math for statistical uniqueness in ULA, while internally >>> correct, is based on some suspect assumptions. If you replace >>> them with worst-case assumptions, the probability of collision >>> when interconnecting two large organizations increases to >>> something on the order of 1 in 1000. Maybe higher if you consider >>> human factors as well. > > Owen> So what... He said he wanted equivalent functionality to > Owen> RFC-1918 where your risk of collision is more like 1 in 3 at > Owen> best and usually 1 in 1 in my experience. > > RFC1918 risk of collision is the reason to argue for IPv6 in the first > place. I work for one company that decided that squatting on 2.0.0.0/8 > for their chassis communications was better than conflicting with RFC1918. > No, RFC-1918 and NAT are among the key reasons to argue for IPv6. Collision is just icing on the cake. > But, I didn't say it was risk of collision with ULA-R that was the > main problem, it is lack of reverse DNS and lack of whois that is the > problem. Why do you need non-local RDNS and/or WHOIS for local-only addresses? If the addresses should not be seen outside of your organization, why would you need a directory service to tell you who the addresses belong to? If the only people that should be seeing (and thus looking up) the addresses in RDNS, then, so long as all of the resolvers in your organization know about your authoritative server for that applicable ip6.arpa zone file, then, you have RDNS. So I don't see those as real problems for proper use of ULA. Owen From joelja at bogus.com Wed May 16 11:35:50 2012 From: joelja at bogus.com (Joel jaeggli) Date: Wed, 16 May 2012 08:35:50 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: References: <4F9E9E39.40501@brightok.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <553FA40D-F426-400E-9542-454FB11C7FF4@delong.com> Message-ID: <4FB3C956.5000600@bogus.com> On 5/16/12 07:47 , William Herrin wrote: > On 5/16/12, Owen DeLong wrote: >> On May 16, 2012, at 5:34 AM, William Herrin wrote: >>> On 5/16/12, Owen DeLong wrote: >>>> Looks to me like the current process is the best of the three even >>>> without >>>> the above correction to your analysis. >>> >>> Until you throw in the missing goal, the one we're discussing in this >>> thread: Until IPv6 use is ubiquitous, barriers to acquiring >>> technically needful IPv6 address assignments should be minimized to >>> the maximum extent practical. >> >> To some extent, I agree with you. However, I don't believe that preemptive >> assignments remove barriers so much as create an illusory consumption. > > I think that's a fair difference of opinion. Short of trying it, I > don't know that it's possible to prove it one way or another. How many glop multicast addresses are you using? I ran out, but I suspect I'm the outlier there. > >>> ARIN policy on IPv6 assignment presents far fewer barriers than it did >>> four years ago, but reasonable analysis grades any resource request >>> from ARIN as "difficult." >> >> I disagree. It took me less than an hour to prepare HE's subsequent >> allocation request for ARIN and submit it. It took less than 48 hours >> for ARIN to issue the requested /24. > From bill at herrin.us Wed May 16 11:54:56 2012 From: bill at herrin.us (William Herrin) Date: Wed, 16 May 2012 11:54:56 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: <1AC3C08D-2754-4ED3-888A-DD761C0E511A@corp.arin.net> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <685CEFF2-D15F-4878-8677-9A3CC7EFB951@delong.com> <1AC3C08D-2754-4ED3-888A-DD761C0E511A@corp.arin.net> Message-ID: On 5/16/12, John Curran wrote: > On May 16, 2012, at 8:34 AM, William Herrin wrote: >> The foundation for a claim that preemptive assignment meaningfully >> harms aggregation is most weak. > > Routing aggregation from preemptive provider-independent assignments > will definitely be much, much less than provider-assigned IPv6 prefixes, > and while there is some chance of aggregation of successive assignments, > it is likely that there are very few such end-user successive assignments > to actually make a meaningful difference. Hi John, Respectfully, that's a false comparison. For the folks I'm talking about, multihomed end users who needed an AS number from ARIN, provider-assigned IPv6 prefixes are technologically not an option. Using ISP-assigned /48s for multihoming is widely blocked by the same kind of filtering which prevents folks from distinctly routing an IPv4 /32 on the public backbone. As with IPv4 /32 announcements, the filtering is not universal but it's broad enough to make the use unworkable. A correct comparison is between preemptively assigned addresses to AS holders and addresses only assigned upon request. In that comparison, increases in disaggregation can only come from two sources: 1. Folks which would not have requested a prefix from ARIN due to an adequate supply from another RIR *and* choose to make use of the ARIN prefix just for the heck of it. 2. Folks which would have correctly sized their assignment upon request, got too small assignment from the preemptive process, need a larger assignment than sparse allocation can accommodate increasing the preemptive assignment to *and* didn't realize it until they were too far into deployment with the preemptive assignment to be willing to give it up. #1 is a technicality at best. Aggregation of address assignments is only important as it relates to aggregation in the routing tables. The number of orgs in situation #1 who don't otherwise disaggregate their routes for North America can be expected to be vanishingly small. #2 requires a whole sequence of improbable events before it results in any aggregation impact. Again, the number of folks who fall into that pitfall with preemptive assignment yet could have avoided it with request-based assignment is likely to be vanishingly small. Actually, I suppose if I'm being fair I talked broadly about preemptively assigning addresses broadly to folks holding IPv4 addresses and folks holding AS numbers. ARIN also assigns IPv4 addresses to large single-homed organizations who, unlike multihomed orgs, face no absolute technological barriers to using ISP addresses. Does your view on aggregation change if discussion is limited to folks holding AS numbers because they needed to multihome? 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 Wed May 16 12:02:21 2012 From: bill at herrin.us (William Herrin) Date: Wed, 16 May 2012 12:02:21 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: <4FB3C956.5000600@bogus.com> References: <4F9E9E39.40501@brightok.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <553FA40D-F426-400E-9542-454FB11C7FF4@delong.com> <4FB3C956.5000600@bogus.com> Message-ID: On 5/16/12, Joel jaeggli wrote: > On 5/16/12 07:47 , William Herrin wrote: >> On 5/16/12, Owen DeLong wrote: >>> On May 16, 2012, at 5:34 AM, William Herrin wrote: >>>> Until you throw in the missing goal, the one we're discussing in this >>>> thread: Until IPv6 use is ubiquitous, barriers to acquiring >>>> technically needful IPv6 address assignments should be minimized to >>>> the maximum extent practical. >>> >>> To some extent, I agree with you. However, I don't believe that >>> preemptive >>> assignments remove barriers so much as create an illusory consumption. >> >> I think that's a fair difference of opinion. Short of trying it, I >> don't know that it's possible to prove it one way or another. > > How many glop multicast addresses are you using? > > I ran out, but I suspect I'm the outlier there. Zero. I have yet to work on a task where multicast looked useful as something other than a replacement for local LAN broadcast. I hear tell such a beast exists but I haven't seen it for myself. 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 Wed May 16 12:07:52 2012 From: bill at herrin.us (William Herrin) Date: Wed, 16 May 2012 12:07:52 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <553FA40D-F426-400E-9542-454FB11C7FF4@delong.com> Message-ID: On 5/16/12, Owen DeLong wrote: > Sure, but, those organizations that might benefit from this proposed > auto-assignment of IPv6 are coming back for additional IPv4 anyway, What makes you think that? Two of the three multihomed orgs I'm responsible for don't have IPv6 addresses yet. One of them won't need more IPv4 addresses for years. I can confidently say that the other won't need more IPv4 addresses ever. IIRC, ARIN stats on the number of end user orgs which ever request an additional assignment support the view that for end users, a timely return for additional addresses is the exception to the rule. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cengel at conxeo.com Wed May 16 12:20:16 2012 From: cengel at conxeo.com (Chris Engel) Date: Wed, 16 May 2012 12:20:16 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) Message-ID: If you are actually talking end-user enterprises here as opposed to transit providers then I would forward that the availability/costs of obtaining IPv6 address space is pretty much a non-factor in inhibiting adoption. There are a TON of other factors which do inhibited adoption. Actually obtaining the space would be trivial in comparison to those. Most of us don't obtain our space through direct assignment anyway, we go through our ISP's/Hosting Companies for it. Right now, for most end enterprises IPv6 is all pain and no gain. Obviously there are special use cases where that is not true, but for the average end enterprise there is absolutely no business case to deploy it other then to pick up a little advanced experience with it as a hedge against future needs. However, in todays work business/atmosphere most of us are struggling to find time/resources to meet business goals that are due in 10 days not 10 years. Not ideal, but it is what is. It's a very fortunate enterprise these days that has spare resources to get ahead of the game and start playing around with things that may or may not become a priority a few years down the line. If engineers are doing that, in most cases they are doing it on their own time. I appreciate that the folks involved with ARIN want to speed IPv6 adoption as much as possible as it will resolve the biggest headache that ARIN faces, managing address scarcity. However, I honestly don't believe there is much of anything ARIN can do policy/pricing/procedure wise to significantly effect adoption of IPv6, at least as far as the end enterprise goes. Most of us won't move on it until we are absolutely forced to do so....which likely for many will be a LONG time coming... it'll be an ugly and painful transition but we'll find a way to muddle through it, as we always have....and eventually with market pressures we'll get the tools and solutions we need to in order to support it well. An interesting anecdote that speaks to where IPv6 still stands on most end enterprises priority list. A few months ago, I attended a local seminar hosted by our preferred firewall/security appliance vendor (Watchguard). During the break, I asked one of the vendors Rep's what the state of IPv6 support was on their latest appliances. I was the only person in the room who mentioned IPv6 at all, and the room included a pretty diverse audience of engineers from both public and private enterprises (local businesses of different sizes, hospitals, schools, police dept's, etc). The rep. stammered for a bit, as he clearly hadn't had anyone else who had raised the issue in recent seminars he had given and then referred the question to one of his colleagues. The colleague proudly proclaimed that they "officially supported it" and then showed me a web page with an "IPv6 Ready" logo/tagline for one of their latest products. The colleague then cautioned me and the rest of those present that under NO circumstances should we actually enable IPv6 support on any of their devices. According to the vendor, "officially supporting IPv6" meant that their firewalls/security appliances were capable of ROUTING IPv6 traffic... however, as the rep. explained, the devices Rules Engine and Packet Inspection Filters were incapable of processing IPv6 packets, so enabling IPv6 support on any of those devices would turn the security appliance/firewall into an OPEN ROUTER, completely bypassing all perimeter security controls. Needless to say, no one present was much interesting in experimenting with such a thing. Now that's anecdotal and I realize it's only one vendor, but I think that speaks alot about where IPv6 still is at in terms of the average end enterprise. Christopher Engel From bill at herrin.us Wed May 16 13:12:15 2012 From: bill at herrin.us (William Herrin) Date: Wed, 16 May 2012 13:12:15 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <504AB22C-864B-4BAC-9928-67E671E78FE2@delong.com> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> <13244.1337104840@marajade.sandelman.ca> <26873.1337181076@marajade.sandelman.ca> <504AB22C-864B-4BAC-9928-67E671E78FE2@delong.com> Message-ID: On 5/16/12, Owen DeLong wrote: > On May 16, 2012, at 8:11 AM, Michael Richardson wrote: >> But, I didn't say it was risk of collision with ULA-R that was the >> main problem, it is lack of reverse DNS and lack of whois that is the >> problem. > > Why do you need non-local RDNS and/or WHOIS for local-only addresses? Hi Owen, Configuring split-horizon DNS coordinated between multiple interconnected organizations has always been a bit of an intractable problem, especially when some parts are connected to some other parts but not all parts are connected to all other parts. You could sometimes get around it with an interior root but DNSSEC blows that out of the water. An exterior NS record back to the interior authoritative server could potentially help a lot. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Wed May 16 13:27:44 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 16 May 2012 10:27:44 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> <13244.1337104840@marajade.sandelman.ca> <26873.1337181076@marajade.sandelman.ca> <504AB22C-864B-4BAC-9928-67E671E78FE2@delong.com> Message-ID: <6ABCC1C0-6DB6-403E-B8D8-78D688CF8F14@delong.com> On May 16, 2012, at 10:12 AM, William Herrin wrote: > On 5/16/12, Owen DeLong wrote: >> On May 16, 2012, at 8:11 AM, Michael Richardson wrote: >>> But, I didn't say it was risk of collision with ULA-R that was the >>> main problem, it is lack of reverse DNS and lack of whois that is the >>> problem. >> >> Why do you need non-local RDNS and/or WHOIS for local-only addresses? > > Hi Owen, > > Configuring split-horizon DNS coordinated between multiple > interconnected organizations has always been a bit of an intractable > problem, especially when some parts are connected to some other parts > but not all parts are connected to all other parts. You could > sometimes get around it with an interior root but DNSSEC blows that > out of the water. An exterior NS record back to the interior > authoritative server could potentially help a lot. > Which makes the situation you describe more ideally suited to GUA with appropriate filtration of routes and packets. Owen From christoph.blecker at ubc.ca Wed May 16 13:44:11 2012 From: christoph.blecker at ubc.ca (Blecker, Christoph) Date: Wed, 16 May 2012 17:44:11 +0000 Subject: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call In-Reply-To: References: <4F9EC985.1030503@arin.net> Message-ID: <5E23819DB192BE43A083C3740C0EF7821FA94671@S-ITSV-MBX01P.ead.ubc.ca> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Heather Schiller > Sent: May-15-12 1:30 PM > To: Jimmy Hess > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-2012-3: ASN Transfers - Last Call > > Sure, ARIN could pursue this type of recovery of ASN's - just like > they could have pursued this kind of recovery for v4. The community > rejected recovery several times, I think for the same reason they > would reject recovery for ASN's. It simply does not address the > underlying desire driving this policy: For the holder of the resource > to choose (or have chosen for them, by a bankruptcy court) who to pass > the resource on to. There is no underlying technical argument to do > so, when a network, equipment or customers do not pass with the number > resource, and those cases are covered by 8.2. I have yet to hear > anyone describe a corner case not covered by 8.2, aside from the > bankruptcy court trying to extract profit for a resource.. a resource > that at other times we claim, derives its value solely from its > uniqueness and the services provided by ARIN. > > So then, why do it? Because, in the case of ASN's where scarcity is > not an issue, the specific order or length of the numbers means > something to the receiver of the resource. Be they short, memorable, > or have some interesting or historical provenance the receiver finds > the specific ASN valuable. > > Unlike ASN's, v4 netblocks are becoming scarce, so folks are > incentivized to reorder their affairs and free up resources. There is > some reasonableness to that, and the idea of financially recovering > what you can in order to cover the expense of renumbering. Will that > be the case with ASN's or will the ASN's that get transferred already > be vacant? The incentive to renumber needs to be high enough to > justify or recover your renumbering costs. Which means that either > there is profit to be made or the resource is unused. If its not in > use, there is no expense for renumbering, so returning it back to the > community is the right thing to do. It's like returning a book to the > library.. I don't understand why the lender holding it should get to > choose who gets to borrow it next. > > I believe thus far, no one has used 8.3 to transfer resources out of > the goodness of their heart - those that believe the resources belong > to the community have returned them to the free pool without regard to > who will receive the resources in the future. > > --Heather I couldn't have said it better. For this and many other of the reasons already stated, I remain in opposition to ARIN-2012-3 being recommended to the board for adoption. Cheers, Christoph From jcurran at arin.net Wed May 16 13:48:04 2012 From: jcurran at arin.net (John Curran) Date: Wed, 16 May 2012 17:48:04 +0000 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <685CEFF2-D15F-4878-8677-9A3CC7EFB951@delong.com> <1AC3C08D-2754-4ED3-888A-DD761C0E511A@corp.arin.net> Message-ID: On May 16, 2012, at 11:54 AM, William Herrin wrote: > On 5/16/12, John Curran wrote: >> >> >> Routing aggregation from preemptive provider-independent assignments >> will definitely be much, much less than provider-assigned IPv6 prefixes, >> and while there is some chance of aggregation of successive assignments, >> it is likely that there are very few such end-user successive assignments >> to actually make a meaningful difference. > > Hi John, > > Respectfully, that's a false comparison. For the folks I'm talking > about, multihomed end users who needed an AS number from ARIN, > provider-assigned IPv6 prefixes are technologically not an option. Bill - I was not asserting that provider-assigned IPv6 prefixes were an option for any particular class of users. What I was pointing out is that a system which provides preemptive provider-independent assignments is very similar to an algorithmic-based assignment scheme in that it completely precludes any form of provider-based routing aggregation, since each new customer with such a prefix results in a new route. > Actually, I suppose if I'm being fair I talked broadly about > preemptively assigning addresses broadly to folks holding IPv4 > addresses and folks holding AS numbers. ARIN also assigns IPv4 > addresses to large single-homed organizations who, unlike multihomed > orgs, face no absolute technological barriers to using ISP addresses. > > Does your view on aggregation change if discussion is limited to folks > holding AS numbers because they needed to multihome? Widespread use of provider-independent IPv6 assignments has been deemed unacceptable in the past by many in the community due to the potential routing impact, and noting that if indeed this assumption has changed (and every multi-homed organization can have their own IPv6 routing entry), then revisiting algorithmic approaches could quickly facilitate making IPv6 address blocks availability to all organizations holding AS numbers, IPv4 address blocks, cell phones, etc. FYI, /John John Curran and CEO ARIN From bill at herrin.us Wed May 16 14:23:52 2012 From: bill at herrin.us (William Herrin) Date: Wed, 16 May 2012 14:23:52 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <685CEFF2-D15F-4878-8677-9A3CC7EFB951@delong.com> <1AC3C08D-2754-4ED3-888A-DD761C0E511A@corp.arin.net> Message-ID: On 5/16/12, John Curran wrote: > I was not asserting that provider-assigned IPv6 prefixes were an option > for any particular class of users. What I was pointing out is that a > system which provides preemptive provider-independent assignments is > very similar to an algorithmic-based assignment scheme in that it > completely precludes any form of provider-based routing aggregation, > since each new customer with such a prefix results in a new route. Hi John, Yes... _ANY_ ARIN direct assignment whether it's preemptive, algorithmic, requested with the existing process or otherwise, precludes all presently-used forms of provider-based routing aggregation. I'm just trying to understand what, if anything, you think is different about preemptive assignment in this respect. > On May 16, 2012, at 11:54 AM, William Herrin wrote: >> Actually, I suppose if I'm being fair I talked broadly about >> preemptively assigning addresses broadly to folks holding IPv4 >> addresses and folks holding AS numbers. ARIN also assigns IPv4 >> addresses to large single-homed organizations who, unlike multihomed >> orgs, face no absolute technological barriers to using ISP addresses. >> >> Does your view on aggregation change if discussion is limited to folks >> holding AS numbers because they needed to multihome? > > Widespread use of provider-independent IPv6 assignments has been deemed > unacceptable in the past by many in the community due to the potential > routing impact, and noting that if indeed this assumption has changed > (and every multi-homed organization can have their own IPv6 routing > entry), 6.5.8.1. Initial Assignment Criteria "meeting one of the following criteria: b. immediately becoming IPv6 Multihomed and using an assigned valid global AS number," It's already ARIN policy (allegedly community consensus policy) that multihoming is an acceptable and appropriate criteria for provider-independent IPv6 assignment. > then revisiting algorithmic approaches could quickly facilitate making > IPv6 address blocks availability to all organizations holding AS > numbers, IPv4 address blocks, cell phones, etc. 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 Wed May 16 16:51:28 2012 From: jcurran at arin.net (John Curran) Date: Wed, 16 May 2012 20:51:28 +0000 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <685CEFF2-D15F-4878-8677-9A3CC7EFB951@delong.com> <1AC3C08D-2754-4ED3-888A-DD761C0E511A@corp.arin.net> Message-ID: <53E58F57-C7B1-49AE-AA73-C86097B5A095@arin.net> On May 16, 2012, at 2:23 PM, William Herrin wrote: > I'm just trying to understand what, if anything, you > think is different about preemptive assignment in this respect. First, an algorithmic assignment (or preemptive assignment for everyone with an IPv4 assignment or an AS number, which effectively will end up being the same in implementation) becomes a permanently change to the IPv6 number resource architecture, i.e. the total space is 100% assigned once the policy is implemented, even if no one one actually puts their individual assignment into productive use. This is significantly different than our existing processes that only assign space based on actual requests (and the resulting assignments are far more likely to put in actual operational use once made based on actual request) Secondly, parties receiving assignments often presume that the operator community will allow the recipient to interconnect to the Internet using their provider-independent assignment; as a result, ARIN encourages the community to consider the potential routing implications of any address issuance policy. The upper bound on preemptively assigning addresses to folks holding AS numbers would (over the long-term) enable an additional 65K routes, and doing the same for folks holding IPv4 addresses could easily result in over 2 million unique IPv6 routes (depending on implementation), if using preemptively-assigned IPv6 blocks became the dominant model of connecting to the Internet. This is a very different outcome then our present IPv6 assignment system, where many organizations make use of IPv6 assignments from their service provider due to convenience, and therefore connect with no direct increase to the IPv6 routing table. This does not mean that a preemptive assignment approach is necessarily good or bad, only that it has different characteristics that the community should consider in the overall balance of making IPv6 more accessible. FYI, /John John Curran President and CEO ARIN From JOHN at egh.com Wed May 16 16:35:18 2012 From: JOHN at egh.com (John Santos) Date: Wed, 16 May 2012 16:35:18 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <504AB22C-864B-4BAC-9928-67E671E78FE2@delong.com> Message-ID: <1120516162526.383A-100000@Ives.egh.com> On Wed, 16 May 2012, Owen DeLong wrote: > > On May 16, 2012, at 8:11 AM, Michael Richardson wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > >>>>>> "Owen" == Owen DeLong writes: > >>> The math for statistical uniqueness in ULA, while internally > >>> correct, is based on some suspect assumptions. If you replace > >>> them with worst-case assumptions, the probability of collision > >>> when interconnecting two large organizations increases to > >>> something on the order of 1 in 1000. Maybe higher if you consider > >>> human factors as well. > > > > Owen> So what... He said he wanted equivalent functionality to > > Owen> RFC-1918 where your risk of collision is more like 1 in 3 at > > Owen> best and usually 1 in 1 in my experience. > > > > RFC1918 risk of collision is the reason to argue for IPv6 in the first > > place. I work for one company that decided that squatting on 2.0.0.0/8 > > for their chassis communications was better than conflicting with RFC1918. > > > > No, RFC-1918 and NAT are among the key reasons to argue for IPv6. > Collision is just icing on the cake. > > > But, I didn't say it was risk of collision with ULA-R that was the > > main problem, it is lack of reverse DNS and lack of whois that is the > > problem. > > Why do you need non-local RDNS and/or WHOIS for local-only addresses? > > If the addresses should not be seen outside of your organization, why would you need a directory service to tell you who the addresses belong to? They *can* be seen in SMTP "Recieved From:" headers. If it's a v4 RFC1918 address, it could have come from anyware. If it's a v6 unique PI or PA address, even if from a non-routable subnet, you can at least track it back to the assignee. If it's v6 ULA with no RDNS, you can't tell where it came from. There may be other examples where internal addresses leak out into the wild. > > If the only people that should be seeing (and thus looking up) the addresses in RDNS, then, so long as all of the resolvers in your organization know about your authoritative server for that applicable ip6.arpa zone file, then, you have RDNS. > > So I don't see those as real problems for proper use of ULA. > > Owen > > > _______________________________________________ > 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. > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From bill at herrin.us Wed May 16 18:08:32 2012 From: bill at herrin.us (William Herrin) Date: Wed, 16 May 2012 18:08:32 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: <53E58F57-C7B1-49AE-AA73-C86097B5A095@arin.net> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <685CEFF2-D15F-4878-8677-9A3CC7EFB951@delong.com> <1AC3C08D-2754-4ED3-888A-DD761C0E511A@corp.arin.net> <53E58F57-C7B1-49AE-AA73-C86097B5A095@arin.net> Message-ID: On 5/16/12, John Curran wrote: > First, an algorithmic assignment (or preemptive assignment for everyone > with an IPv4 assignment or an AS number, which effectively will end up > being the same in implementation) becomes a permanently change to the > IPv6 number resource architecture, i.e. the total space is 100% assigned > once the policy is implemented, even if no one one actually puts their > individual assignment into productive use. Hi John, For an algorithmic assignment (insert you address/ASN in this spot in the address), this statement is true. The holder of the source number is entitled to the destination number, regardless of his use or relationship with ARIN and all source numbers are represented even if not assigned. For a preemptive non-algorithmic assignment (pull a list from the database on criteria X and assign each resulting record an IPv6 block in sequence) there is no reason numbers should be lost to non-use. A process could easily include non-use reclamation criteria. Arguably it _should_ include non-use reclamation criteria as a deployment incentive: We'll give you these addresses for free but if you don't use them by Date we'll take them back and next time you'll have to pay for them. > This is significantly > different than our existing processes that only assign space based > on actual requests (and the resulting assignments are far more likely > to put in actual operational use once made based on actual request) Agreed. > Secondly, parties receiving assignments often presume that the operator > community will allow the recipient to interconnect to the Internet using > their provider-independent assignment; as a result, ARIN encourages the > community to consider the potential routing implications of any address > issuance policy. The upper bound on preemptively assigning addresses to > folks holding AS numbers would (over the long-term) enable an additional > 65K routes, and doing the same for folks holding IPv4 addresses could > easily > result in over 2 million unique IPv6 routes (depending on implementation), Hold on now, ARIN doesn't have 2 million unique organizations all holding direct IPv4 assignments or allocations, does it? That smells at least an order of magnitude off base. 2 million IPv4 registrations I could believe but 2 million unique organizations holding them? Regardless, let's pick a bite-sized starting point: Every ARIN-assigned AS number which also appears in the public Internet BGP table. Per Geoff Huston (http://www.potaroo.net/tools/asn32/) that's no more than 15086 today climbing about what, 50ish per week? Do you have reason to believe the upper bound on this criteria would exceed 16,000 IPv6 assignments? Aggregable to less than 16,000 routes? 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 Wed May 16 18:25:47 2012 From: jcurran at arin.net (John Curran) Date: Wed, 16 May 2012 22:25:47 +0000 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <685CEFF2-D15F-4878-8677-9A3CC7EFB951@delong.com> <1AC3C08D-2754-4ED3-888A-DD761C0E511A@corp.arin.net> <53E58F57-C7B1-49AE-AA73-C86097B5A095@arin.net> Message-ID: <5A150FEC-104E-4C97-A6B0-2EC7CF32BA83@arin.net> On May 16, 2012, at 6:08 PM, William Herrin wrote: >> The upper bound on preemptively assigning addresses to >> folks holding AS numbers would (over the long-term) enable an additional >> 65K routes, and doing the same for folks holding IPv4 addresses could >> easily >> result in over 2 million unique IPv6 routes (depending on implementation), > > Hold on now, ARIN doesn't have 2 million unique organizations all > holding direct IPv4 assignments or allocations, does it? That smells > at least an order of magnitude off base. 2 million IPv4 registrations > I could believe but 2 million unique organizations holding them? Bill - I said _over the long-term_, please think decades. There is nothing to prevent parties from holding multiple IPv4 blocks, and in fact, you may have just created an interesting incentive for parties many years from today to seek out IPv4 blocks (i.e. entirely for the preemptively & non-provider assigned IPv6 prefixes which are associated with them...) We're unlikely to see that in the near future, but depending on the specifics it could be rather difficult to undo any preemptive IPv6 assignment scheme and hence giving some consideration to the resulting long-term implications would be quite prudent. Thanks, /John John Curran President and CEO ARIN From bill at herrin.us Wed May 16 18:39:30 2012 From: bill at herrin.us (William Herrin) Date: Wed, 16 May 2012 18:39:30 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: <5A150FEC-104E-4C97-A6B0-2EC7CF32BA83@arin.net> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <685CEFF2-D15F-4878-8677-9A3CC7EFB951@delong.com> <1AC3C08D-2754-4ED3-888A-DD761C0E511A@corp.arin.net> <53E58F57-C7B1-49AE-AA73-C86097B5A095@arin.net> <5A150FEC-104E-4C97-A6B0-2EC7CF32BA83@arin.net> Message-ID: On 5/16/12, John Curran wrote: > On May 16, 2012, at 6:08 PM, William Herrin wrote: >> Hold on now, ARIN doesn't have 2 million unique organizations all >> holding direct IPv4 assignments or allocations, does it? That smells >> at least an order of magnitude off base. 2 million IPv4 registrations >> I could believe but 2 million unique organizations holding them? > > I said _over the long-term_, please think decades. There is nothing > to prevent parties from holding multiple IPv4 blocks, and in fact, you > may have just created an interesting incentive for parties many years > from today to seek out IPv4 blocks (i.e. entirely for the preemptively > & non-provider assigned IPv6 prefixes which are associated with them...) Hi John, I've been talking about a one-shot deal. Get 15,000ish address blocks out there. Once. Then treat them like any other block held under that org's registration services agreement. What are you talking about? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Wed May 16 20:09:34 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 16 May 2012 17:09:34 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <1120516162526.383A-100000@Ives.egh.com> References: <1120516162526.383A-100000@Ives.egh.com> Message-ID: >> >>> But, I didn't say it was risk of collision with ULA-R that was the >>> main problem, it is lack of reverse DNS and lack of whois that is the >>> problem. >> >> Why do you need non-local RDNS and/or WHOIS for local-only addresses? >> >> If the addresses should not be seen outside of your organization, why > would you need a directory service to tell you who the addresses belong > to? > > They *can* be seen in SMTP "Recieved From:" headers. If it's a v4 RFC1918 > address, it could have come from anyware. If it's a v6 unique PI or PA > address, even if from a non-routable subnet, you can at least track it > back to the assignee. If it's v6 ULA with no RDNS, you can't tell where > it came from. > So, at worst, you are in the same boat with ULA as with IPv4 RFC-1918. Clearly the enterprise world has deemed that mess as an acceptable one. Personally, I think ULA is a really bad thing overall and that GUA with registration makes far more sense. If you don't want it outside, filter the routes and the packets at your borders. > There may be other examples where internal addresses leak out into the > wild. > Indeed, but, unless you can show a way in which the IPv6 ULA situation is worse than the current IPv4 RFC-1918 situation, then, I fail to see how this is in any way a reason not to deploy IPv6. The original claim I was responding to was that in order to deploy IPv6, enterprises need non-public addresses. ULA meets that test at least as well as whatever they have in IPv4. Owen From jcurran at arin.net Wed May 16 21:50:05 2012 From: jcurran at arin.net (John Curran) Date: Thu, 17 May 2012 01:50:05 +0000 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <685CEFF2-D15F-4878-8677-9A3CC7EFB951@delong.com> <1AC3C08D-2754-4ED3-888A-DD761C0E511A@corp.arin.net> <53E58F57-C7B1-49AE-AA73-C86097B5A095@arin.net> <5A150FEC-104E-4C97-A6B0-2EC7CF32BA83@arin.net> Message-ID: <292BF39A-527C-41E5-B952-AE0157D453A9@arin.net> On May 16, 2012, at 6:39 PM, William Herrin wrote: > > Hi John, > > I've been talking about a one-shot deal. Get 15,000ish address blocks > out there. Once. Then treat them like any other block held under that > org's registration services agreement. Bill - Ah, thank you, that clarifies things significantly. Agreed, if you simply pull all resource holders meeting criteria "X" and preemptively assign each an IPv6 block, then you can't end up with more new direct routes than blocks issued. I have no idea if it that approach will materially affect IPv6 deployment, but it should be implementable as you describe above and in the previous message. Please remember, if you move to proposing it, to specify whether and/or how ARIN is to deal with reclamation and how this one-time event would be equitable to those organizations seeking IPv6 space at time after your one-time event. Thanks! /John John Curran President and CEO ARIN From mcr at sandelman.ca Wed May 16 22:11:30 2012 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 16 May 2012 22:11:30 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: <504AB22C-864B-4BAC-9928-67E671E78FE2@delong.com> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> <13244.1337104840@marajade.sandelman.ca> <26873.1337181076@marajade.sandelman.ca> <504AB22C-864B-4BAC-9928-67E671E78FE2@delong.com> Message-ID: <16514.1337220690@marajade.sandelman.ca> >>>>> "Owen" == Owen DeLong writes: Owen> No, RFC-1918 and NAT are among the key reasons to argue for Owen> IPv6. Collision is just icing on the cake. For *INTERNET* access, you are right. I'm talking about systems which do not (intentionally) exchange packets with the Internet, but which use IP addressing "internally"(%) to communicate, and at the edge of these devices, they speak to an Enterprise network of some kind. (%)-"internally" is in quotes, because, in one case, the network plans to span many miles of tundra. 1) The leak potential is large due to misconfiguration. Sometimes bits of the Enterprise are used as "backbone" for these systems. (That's why layer-3 IP networking is so useful...) When the packets escape into some part of the Enterprise which does not know about said device, people start asking whois. ULA-Random may be just fine for a homenet network, but I'd never want to have it an Enterprise. 2) what if there are two of these devices, or two enterprises with these devices merge? I can't see why the *manufacturer* of said device can't trivially get a /48 or /40 in Non-Connected space, and then stamp in a /56 or /60 (as appropriate) into each instance sold. Look at ethernet... you pay the IEEE $2500 once, you get your OUI prefix. Done, no renewal necessary. It's hard enough to justify that $2500 once... but $1250 every year? "Thanks, this IPv6 stuff is too difficult, we'll just squat on something. IPv6 ULA-R gives us no advantage over RFC1918 or squatting." (Actually, IPv4 squatting is better, because if the manufacturer puts something useful on a web site about where they squat, google can find it when whois returns nonsense) >> But, I didn't say it was risk of collision with ULA-R that was >> the main problem, it is lack of reverse DNS and lack of whois >> that is the problem. Owen> Why do you need non-local RDNS and/or WHOIS for local-only Owen> addresses? Why do I see large ISPs with multiple ASs? Why isn't all their traffic local? Why aren't their networks convex? See above. One hand does not know what the other hand is doing, and does not need to. Owen> If the addresses should not be seen outside of your Owen> organization, why would you need a directory service to tell Owen> you who the addresses belong to? emphasis on "SHOULD" Take two windows laptops at two enterprises a floor apart, turn on wifi bridging on both. Now try to figure out where the packets are coming from. With RFC1918 it's already a disaster. IPv6 doesn't need to suck that way. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: not available URL: From mcr at sandelman.ca Wed May 16 22:34:12 2012 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 16 May 2012 22:34:12 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: Message-ID: <20586.1337222052@marajade.sandelman.ca> >>>>> "Chris" == Chris Engel writes: Chris> If you are actually talking end-user enterprises here as No, *I* am not talking about addresses for enterprises own use. (I believe that William Herrin has many COIN examples though) I'm talking about enterprises which create products which use IP addressing internally. Said products get sold/shipped/instantiated (for VMs) to other enterprises. Many of these things are greenfields as far as networking goes. This is where much of the win of IPv6 is. Chris> I appreciate that the folks involved with ARIN want to speed Chris> IPv6 adoption as much as possible as it will resolve the Chris> biggest headache that ARIN faces, managing address Chris> scarcity. However, I honestly don't believe there is much of Right, but what we have right now is IPv6 artificial scarcity. Chris> of their devices. According to the vendor, "officially Chris> supporting IPv6" meant that their firewalls/security Chris> appliances were capable of ROUTING IPv6 traffic... however, Chris> as the rep. explained, the devices Rules Engine and Packet Chris> Inspection Filters were incapable of processing IPv6 packets, Chris> so enabling IPv6 support on any of those devices would turn Chris> the security appliance/firewall into an OPEN ROUTER, Nice. Thanks for this. A firewall vendor to avoid, since they spent all this money on that logo, and none on thinking. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: not available URL: From owen at delong.com Thu May 17 06:41:13 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 17 May 2012 03:41:13 -0700 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: <16514.1337220690@marajade.sandelman.ca> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> <13244.1337104840@marajade.sandelman.ca> <26873.1337181076@marajade.sandelman.ca> <504AB22C-864B-4BAC-9928-67E671E78FE2@delong.com> <16514.1337220690@marajade.sandelman.ca> Message-ID: <67A19555-06EA-4979-90F0-99890E82C375@delong.com> On May 16, 2012, at 7:11 PM, Michael Richardson wrote: > >>>>>> "Owen" == Owen DeLong writes: > Owen> No, RFC-1918 and NAT are among the key reasons to argue for > Owen> IPv6. Collision is just icing on the cake. > > For *INTERNET* access, you are right. I believe this applies just as well to systems which do not (intentionally) exchange packets with the internet, but which use IP addressing. Indeed, these systems fall into one of two categories (I will explain below). > I'm talking about systems which do not (intentionally) exchange packets > with the Internet, but which use IP addressing "internally"(%) to > communicate, and at the edge of these devices, they speak to an > Enterprise network of some kind. There are two categories of "internal only" networks. One is isolated networks which are entirely self-contained and do not touch any networks which interact with the internet. These networks can be assembled with any address space without regard to internet numbering. The other is semi-private networks in that they do not directly exchange packets with the internet, but, they touch and exchange packets with networks that do. These networks do, indeed, need locally (at least) unique addressing which does not conflict with external internet addressing. For such addressing, one has two options... GUA and ULA. In either case, IPv6 provides the advantages of avoiding RFC-1918 and NAT. Sure, you might be able to do IPv4 in some instances of both cases without using RFC-1918 and/or NAT, but it is relatively unlikely at any scale and almost certainly impossible across a few mergers and acquisitions of any size. (We were talking enterprise, not SMB here, right?) > > (%)-"internally" is in quotes, because, in one case, the network plans > to span many miles of tundra. > "Internal" is a matter of topology, not geography. > 1) The leak potential is large due to misconfiguration. Sometimes > bits of the Enterprise are used as "backbone" for these systems. > (That's why layer-3 IP networking is so useful...) > When the packets escape into some part of the Enterprise which does > not know about said device, people start asking whois. > ULA-Random may be just fine for a homenet network, but I'd never want > to have it an Enterprise. So why not use GUA? Policy allows you to use GUA for such purposes. Filter these GUA routes at the border and filter the packets too, just in case. Unless you have two parallel misconfigurations (routing _AND_ packet filters), you won't have external leaks. This solves your desire for whois and RDNS. There's no need to do complex split horizon, just use DNS views (easy with BIND, not sure about other tools). Indeed, not even really a need to register your RDNS servers globally so long as the resolvers on the enterprise networks you touch have NS cache hints pointing in the right direction for those zones. > > 2) what if there are two of these devices, or two enterprises with these > devices merge? I can't see why the *manufacturer* of said device > can't trivially get a /48 or /40 in Non-Connected space, and then > stamp in a /56 or /60 (as appropriate) into each instance sold. > Again, not seeing a problem with using GUA for this, though I fail to understand why addressing would be applied by the manufacturer rather than configured by the administrator. > Look at ethernet... you pay the IEEE $2500 once, you get your OUI > prefix. Done, no renewal necessary. It's hard enough to justify > that $2500 once... but $1250 every year? The short answer is that layer 3 addressing operates in an entirely different context from layer 2 addressing. Layer 3 addressing must be globally unique. Layer 2 addressing only needs to be unique within a link. Layer 2 addressing operates in a completely flat topology. Layer 3 addresses are hierarchical and contain and/or define a certain amount of topological information. > > "Thanks, this IPv6 stuff is too difficult, we'll just squat on > something. IPv6 ULA-R gives us no advantage over RFC1918 or > squatting." > The ideal solution for what you describe is GUA. You are right, ULA is no better and no worse than RFC-1918. > (Actually, IPv4 squatting is better, because if the manufacturer puts > something useful on a web site about where they squat, google can > find it when whois returns nonsense) In fact, not true. You can put something useful on the web site about where you located in ULA-R and have a reasonable chance that google finds only your squat and not 5,000 other squatters using the same space. > > >>> But, I didn't say it was risk of collision with ULA-R that was >>> the main problem, it is lack of reverse DNS and lack of whois >>> that is the problem. > > Owen> Why do you need non-local RDNS and/or WHOIS for local-only > Owen> addresses? > > Why do I see large ISPs with multiple ASs? > Why isn't all their traffic local? Why aren't their networks convex? > If they were entirely internal non-connected networks, you wouldn't. They are not. They are globally connected networks and their internal structures are exposed in order to facilitate better routing where they touch the internet. > See above. > One hand does not know what the other hand is doing, and does not need to. > Quite the opposite, actually. > Owen> If the addresses should not be seen outside of your > Owen> organization, why would you need a directory service to tell > Owen> you who the addresses belong to? > > emphasis on "SHOULD" > > Take two windows laptops at two enterprises a floor apart, turn on wifi > bridging on both. Now try to figure out where the packets are coming > from. With RFC1918 it's already a disaster. IPv6 doesn't need to suck > that way. > Indeed, it doesn't suck that way unless you make it do so. ULA does, indeed suck just as bad as RFC-1918. If you don't want that suckage, use GUA. I'm all for distributing more GUA at lower fees. If you use ULA, it's free, but, you get what you pay for. Owen From cgrundemann at gmail.com Thu May 17 11:21:10 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 17 May 2012 09:21:10 -0600 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: <67A19555-06EA-4979-90F0-99890E82C375@delong.com> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> <13244.1337104840@marajade.sandelman.ca> <26873.1337181076@marajade.sandelman.ca> <504AB22C-864B-4BAC-9928-67E671E78FE2@delong.com> <16514.1337220690@marajade.sandelman.ca> <67A19555-06EA-4979-90F0-99890E82C375@delong.com> Message-ID: On Thu, May 17, 2012 at 4:41 AM, Owen DeLong wrote: > On May 16, 2012, at 7:11 PM, Michael Richardson wrote: >> ? Look at ethernet... you pay the IEEE $2500 once, you get your OUI >> ? prefix. ?Done, no renewal necessary. ?It's hard enough to justify >> ? that $2500 once... but $1250 every year? > The short answer is that layer 3 addressing operates in an entirely > different context from layer 2 addressing. Layer 3 addressing must be > globally unique. Layer 2 addressing only needs to be unique within > a link. Layer 2 addressing operates in a completely flat topology. > Layer 3 addresses are hierarchical and contain and/or define a > certain amount of topological information. The more I understand this position, the more it sounds like what is being asked for is simply "free" GUA. Two things on that: First, PA GUA (IPv6 addresses from your provider) should cost you nothing additional to what you already must pay for Internet access (assuming you have access for any one machine in your network - the addresses do not have to be used to connect to the Internet). In fact, even a free IPv6 tunnel comes with a free /48... Second, if you want/need PI GUA as an end-user (not an ISP), there is a one time fee and a $100/year maint. fee, not $1250 every year (the higher yearly fees are for ISPs, if you are not connecting customers to the Internet, I assume you would qualify as an end-user). Do neither of these meet your needs? How not? And how does any of this (PA GUA, PI GUA, ULA) make IPv6 worse than IPv4? Thanks for your insight, ~Chris -- @ChrisGrundemann http://chrisgrundemann.com From mysidia at gmail.com Thu May 17 19:21:53 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 17 May 2012 18:21:53 -0500 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: <5A150FEC-104E-4C97-A6B0-2EC7CF32BA83@arin.net> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <685CEFF2-D15F-4878-8677-9A3CC7EFB951@delong.com> <1AC3C08D-2754-4ED3-888A-DD761C0E511A@corp.arin.net> <53E58F57-C7B1-49AE-AA73-C86097B5A095@arin.net> <5A150FEC-104E-4C97-A6B0-2EC7CF32BA83@arin.net> Message-ID: On 5/16/12, John Curran wrote: > On May 16, 2012, at 6:08 PM, William Herrin wrote: > I said _over the long-term_, please think decades. There is nothing When I think decades... I think "lots of time to solve the problem", which isn't that bad. Even if the solution that is adopted requires router hardware upgrades (so sad), even if the solution ultimately involves providers becoming "picky" about what they will route for a customer; even if it ultimately requires an application to an IP address registry for each ROUTE, in order to get the digitally signed certificate required to originate a route, with a limit of 1 certificate per organization and "Required technical justification other than avoiding renumbering for utilizing PI". It's still a better problem than "The IPv6 routing table is still mostly empty, because hardly anyone deployed the protocol" > to prevent parties from holding multiple IPv4 blocks, and in fact, you > may have just created an interesting incentive for parties many years > from today to seek out IPv4 blocks (i.e. entirely for the preemptively > & non-provider assigned IPv6 prefixes which are associated with them...) It's possible to offer preemptive assignment, with a "requirement to report usage of the prefix", before putting it to use. As soon as it is no longer useful for encouraging IPv6 deployment, retiring the preemptive block, excepting reported prefixes, would be an option. -- -JH From astrodog at gmx.com Thu May 17 23:58:47 2012 From: astrodog at gmx.com (Astrodog) Date: Thu, 17 May 2012 22:58:47 -0500 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: References: <4F9E9E39.40501@brightok.net> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <685CEFF2-D15F-4878-8677-9A3CC7EFB951@delong.com> <1AC3C08D-2754-4ED3-888A-DD761C0E511A@corp.arin.net> Message-ID: <4FB5C8F7.8020101@gmx.com> [snip] > > Widespread use of provider-independent IPv6 assignments has been deemed > unacceptable in the past by many in the community due to the potential > routing impact, and noting that if indeed this assumption has changed > (and every multi-homed organization can have their own IPv6 routing entry), > then revisiting algorithmic approaches could quickly facilitate making > IPv6 address blocks availability to all organizations holding AS numbers, > IPv4 address blocks, cell phones, etc. > > This is an interesting concern to me as the majority of the organizations I work with are end-user assignees that route little to no traffic that is not destined specifically for them, or something they're originating. (Though, in some cases, they have peered with providers who wanted to run transit on their internal back-haul) The number of organizations electing to multi-home their connections is likely to only increase as they become more and more dependent on internet connectivity to conduct their business. In my industry, this particular trend is accelerating very rapidly, as running things like drilling operations remotely, while depending on a single provider is considered an incredibly risky proposition, regardless of what an SLA states. Making it more difficult for organizations to obtain a provider independent allocation does ease the burden on routing equipment, but only at the cost of interfering with how end-users use their connectivity, forcing them into things trying to manage traffic with tools ill-suited to the task, such as low TTL DNS records, carrier NAT, or in one notable case, a strange trade of VPN connections with various other entities to allow all of them access to addresses in the others' space. It also serves to force them in to maintaining a relationship with a single provider, due to re-numbering pain. I do not see these organizations sacrificing the huge advantages of provider-independent addressing, simply to allow external organizations to avoid purchasing additional or upgraded equipment. As it stands now, these organizations qualify under ARIN's requirements. Is it the intent of the community to tighten the rules? The routing problems created by provider-independent addressing are unavoidable, as more and more organizations determine that it is not in their interests to tie their addressing to a single provider. I do not believe it is in the interests of the community to attempt to frustrate these efforts, as most of the alternatives are worse, and the organizations involved are unlikely to comply willingly. One provider may refuse to route them and broadcast the routes, but for a large enough check *someone* will. --- Harrison From narten at us.ibm.com Fri May 18 00:53:04 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 18 May 2012 00:53:04 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201205180453.q4I4r4QM015963@rotala.raleigh.ibm.com> Total of 109 messages in the last 7 days. script run at: Fri May 18 00:53:04 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 18.35% | 20 | 19.35% | 173532 | owen at delong.com 17.43% | 19 | 16.73% | 150076 | bill at herrin.us 12.84% | 14 | 11.04% | 99021 | mysidia at gmail.com 9.17% | 10 | 8.38% | 75165 | jcurran at arin.net 7.34% | 8 | 7.25% | 65008 | cgrundemann at gmail.com 5.50% | 6 | 4.80% | 43035 | izaac at setec.org 4.59% | 5 | 3.82% | 34280 | paul at redbarn.org 3.67% | 4 | 3.59% | 32208 | mcr at sandelman.ca 2.75% | 3 | 3.95% | 35449 | tvest at eyeconomics.com 2.75% | 3 | 3.53% | 31622 | drake.pallister at duraserver.com 2.75% | 3 | 2.65% | 23809 | astrodog at gmx.com 0.92% | 1 | 2.04% | 18306 | mjoseph at google.com 0.92% | 1 | 1.82% | 16300 | kkargel at polartel.com 0.92% | 1 | 1.23% | 10990 | heather.skanks at gmail.com 0.92% | 1 | 1.19% | 10715 | dogwallah at gmail.com 0.92% | 1 | 1.17% | 10530 | scottleibrand at gmail.com 0.92% | 1 | 0.94% | 8471 | hannigan at gmail.com 0.92% | 1 | 0.93% | 8299 | christoph.blecker at ubc.ca 0.92% | 1 | 0.92% | 8221 | info at arin.net 0.92% | 1 | 0.89% | 7972 | cengel at conxeo.com 0.92% | 1 | 0.87% | 7785 | narten at us.ibm.com 0.92% | 1 | 0.78% | 7024 | john at egh.com 0.92% | 1 | 0.78% | 6957 | joelja at bogus.com 0.92% | 1 | 0.70% | 6302 | springer at inlandnet.com 0.92% | 1 | 0.65% | 5816 | mike at nationwideinc.com --------+------+--------+----------+------------------------ 100.00% | 109 |100.00% | 896893 | Total From jcurran at arin.net Fri May 18 06:44:50 2012 From: jcurran at arin.net (John Curran) Date: Fri, 18 May 2012 10:44:50 +0000 Subject: [arin-ppml] Encouraging IPv6 Transition In-Reply-To: <4FB5C8F7.8020101@gmx.com> References: <4F9E9E39.40501@brightok.net> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <29EA210A-64AC-4C1F-82F7-71F38D9C70BE@delong.com> <685CEFF2-D15F-4878-8677-9A3CC7EFB951@delong.com> <1AC3C08D-2754-4ED3-888A-DD761C0E511A@corp.arin.net> <4FB5C8F7.8020101@gmx.com> Message-ID: On May 17, 2012, at 11:58 PM, Astrodog wrote: >> Widespread use of provider-independent IPv6 assignments has been deemed >> unacceptable in the past by many in the community due to the potential >> routing impact, ... > As it stands now, these organizations qualify under ARIN's requirements. > Is it the intent of the community to tighten the rules? The routing > problems created by provider-independent addressing are unavoidable, as > more and more organizations determine that it is not in their interests > to tie their addressing to a single provider. I do not believe it is in > the interests of the community to attempt to frustrate these efforts, as > most of the alternatives are worse, and the organizations involved are > unlikely to comply willingly. One provider may refuse to route them and > broadcast the routes, but for a large enough check *someone* will. Harrison - Actually, my statement was more inclined towards past views than any indication of what is coming. In particular, each time there has been discussion of widespread IPv6 provider- independent end-user assignments in the IETF, it has been deemed not viable from technical perspective. The difference between allowing end-users to qualify for a provider-independent IPv6 block from the registry and having all end-users automatically have a PI assignment comes down to whether each new Internet connection results in a unique route in the IPv6 DFZ. Tens of thousands of new routes are likely no problem, whereas millions of new routes gets fun. Our present model has the vast majority of new IPv6 customers using provider-assigned IPv6 space, which means we see the benefit of aggregation in the resulting routing. Obviously, this doesn't apply for multi-homed IPv6 organizations who go and get their own IPv6 assignment, but I'm told that such organizations are a small minority of new IPv6 connections. So, my statement was not reflective of any intent to change the current model, but only to point out that there has been consideration in the past of going to entirely to provider- independent schemes for IPv6 end-user organizations (such as could be obtained with a purely algorithmic assignment scheme) and one outcome of that type of change would be undoing the present aggregation benefits which happen in under the current architecture by default. FYI, /John John Curran President and CEO ARIN From jmaimon at chl.com Fri May 18 12:36:01 2012 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 18 May 2012 12:36:01 -0400 Subject: [arin-ppml] Clarify /29 assignment identification requirement In-Reply-To: References: Message-ID: <4FB67A71.8030105@chl.com> 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. > I support the proposal as written in either version. (It is troubling how we waffle between specificity and ambiguity) I hope to see it continued to be discussed further, along with what I see as the larger picture involved. I read this proposal with the perspective that ARIN has always had a huge discretion in deciding what level of documentation and which circumstances meet their threshold for satisfying the documented policy requirements. That is perfectly normal. After all, dealing with customer requests is mostly the same way. Eventually, you arrive at the bottom line. I know justified utilization when I see it and the more I see of it, the more discerning my vision gets. What is also going on is that the barrier to satisfying ARIN has been rising at a similar rate to the dissipation of the available IPv4 resources. This is also natural and likely also how we deal with our customer requests as well. Yes, that results in historical and size imbalances, with incumbents and experienced entities more likely to be advantaged than others. Also perfectly normal and natural, unfortunate as it may appear to many. Recently we have arrived at the point where proposals such as these will seek to head off the natural progression of the ARIN satisfaction threshold. I believe that is inevitable. I believe this proposal is not nearly as radical as some other would be. I also do not believe the proposal is an actual solution to the overall issue. It is simply not possible to artificially check the progression of the satisfaction threshold with ever increasing scarcity, not to mention the well known bureaucratic scope creep effect. In short, going down this path is likely to result in never ending attempts to refine, restrict, define and control the methods ARIN is to use in an attempt to substitute the communities satisfaction threshold with ARIN's internally developed one. I am not sure it is possible, I am not certain it is a useful expenditure of effort and I doubt very much the end result would be any different. All that aside, I do believe it is time to start dealing more forthrightly with this issue and as such I support this proposal, as its discussion and adoption may serve to better focus our attention on this aspect of IPv4 scarcity. Best, Joe From micah at riseup.net Fri May 18 12:44:52 2012 From: micah at riseup.net (micah anderson) Date: Fri, 18 May 2012 12:44:52 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: Message-ID: <87pqa1h20r.fsf@algae.riseup.net> Chris Engel writes: > If you are actually talking end-user enterprises here as opposed to > transit providers then I would forward that the availability/costs of > obtaining IPv6 address space is pretty much a non-factor in inhibiting > adoption. Its the main reason inhibiting our initial adoption. We may have other reasons once we have the IP space, but until we do, or until we have the possibility of spending the money on the space, we aren't even going to consider tackling the other reasons. From cgrundemann at gmail.com Fri May 18 13:43:10 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 18 May 2012 11:43:10 -0600 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: <87pqa1h20r.fsf@algae.riseup.net> References: <87pqa1h20r.fsf@algae.riseup.net> Message-ID: On Fri, May 18, 2012 at 10:44 AM, micah anderson wrote: > Chris Engel writes: > >> If you are actually talking end-user enterprises here as opposed to >> transit providers then I would forward that the availability/costs of >> obtaining IPv6 address space is pretty much a non-factor in inhibiting >> adoption. > > Its the main reason inhibiting our initial adoption. We may have other > reasons once we have the IP space, but until we do, or until we have the > possibility of spending the money on the space, we aren't even going to > consider tackling the other reasons. Why is it inhibiting you specifically? Can you not get PA space from your upstream? Or is that not an option for some other reason? Have you considered using a tunnel to get your toes wet with IPv6? ~Chris > _______________________________________________ > 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 info at arin.net Fri May 18 13:48:00 2012 From: info at arin.net (ARIN) Date: Fri, 18 May 2012 13:48:00 -0400 Subject: [arin-ppml] ARIN-prop-168 Promote 4byte ASN Usage In-Reply-To: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> Message-ID: <4FB68B50.5070803@arin.net> ARIN-prop-168 Promote 4byte ASN Usage The proposal originator revised the proposal. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-168 Promote 4byte ASN Usage Proposal Originator: Joe Maimon Proposal Version: 1.1 Date: 18 May 2012 Proposal type: Modify Policy term: Temporary Policy statement: Add section 5.2 5.2 Guidelines ARIN will issue AS Numbers under the following guidelines. 5.2.1 Unused ARIN will attempt to assign to the organization an AS Number which has neither been previously assigned nor publicly used, as available. 5.2.2 Requests An organization may request from ARIN either a specific AS Number or type of AS Number, if available to ARIN. The organization must document to ARIN's satisfaction technical or real world justification for its request. ARIN may review the data directly with all involved parties. 5.2.3 Rectification ARIN may reuse the provided documentation in such public and private forums as it deems appropriate and useful to promote the rectification of issues documented via 5.2.2 request justification. 5.2.4 Restrictions Assignments received via 5.2.2 requests are additionally restricted from 8.3 transfers for a period of 24 months post assignment. 5.2.5 Release An organization can exchange the 5.2.2 number for a 5.2.1 number, after which time the restriction on transferring the assignment will be released. 5.2.6 Publication Section 5.2 neither requires nor recommends that ARIN publicize its available AS Numbers. 5.2.7 Expiration ARIN may retire section 5.2 anytime during a period of more than 24 calendar months that have gone by without any completed 5.2.2 requests. Rationale: Changes from V1.0 5.2.1 "used" -> "publicly used" 5.2.2 "must provide" -> "must document" 5.2.2 "technical justification " -> "technical or real world justification" 5.2.3 strike "with suitable privacy considerations in place" 5.2.3 "public forums" -> "public or private forums" 5.2.3 "necessary to promote" -> "appropriate and useful to promote" 5.2.3 "rectification of documented causes" -> "rectification of issues documented via 5.2.2 request justification" 5.2.4 "being transferred" -> "from 8.3 transfers" 5.2.7 "after a period of" -> "during a period of more than" Unless otherwise requested, providing an ASN with no baggage or history should be preferential to both the organization and to ARIN. The restrictions and clauses regarding technical justification are designed for the promotion of 4byte ASN uptake and preservation of 2byte ASN's for those who truly need them. Additionally, this may help to assist in resolving apparently pervasive obstacles in the ARIN region to using 4byte ASN's. Further, if an organization does have a valid technical justification for a specific AS Number that is available, for example, when a network was built with an ASN that was subsequently reclaimed due to accidental negligence or other similar cases, there is little benefit to ARIN refusing to provide the organization what it can show it needs. ARIN need not publicize available ASNs but it may choose to do so if it is the most efficient and prudent method of implementation. Should this policy become a relic (we hope), ARIN is expressly authorized to excise it. Timetable for implementation: Immediate. From micah at riseup.net Fri May 18 14:40:25 2012 From: micah at riseup.net (micah anderson) Date: Fri, 18 May 2012 14:40:25 -0400 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: References: <87pqa1h20r.fsf@algae.riseup.net> Message-ID: <878vgpgwo6.fsf@algae.riseup.net> Chris Grundemann writes: > On Fri, May 18, 2012 at 10:44 AM, micah anderson wrote: >> Chris Engel writes: >> >>> If you are actually talking end-user enterprises here as opposed to >>> transit providers then I would forward that the availability/costs of >>> obtaining IPv6 address space is pretty much a non-factor in inhibiting >>> adoption. >> >> Its the main reason inhibiting our initial adoption. We may have other >> reasons once we have the IP space, but until we do, or until we have the >> possibility of spending the money on the space, we aren't even going to >> consider tackling the other reasons. > > Why is it inhibiting you specifically? The amount might not seem like much, but when you are a nonprofit (501(c)3 or 501(c)4), finances are quite tight. > Can you not get PA space from your upstream? Or is that not an option > for some other reason? We can, but having PI space from the beginning saves us significantly when it comes time to renumber. > Have you considered using a tunnel to get your toes wet with IPv6? Did that ages ago. From marka at isc.org Mon May 21 08:38:45 2012 From: marka at isc.org (Mark Andrews) Date: Mon, 21 May 2012 22:38:45 +1000 Subject: [arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement) In-Reply-To: Your message of "Wed, 16 May 2012 10:27:44 MST." <6ABCC1C0-6DB6-403E-B8D8-78D688CF8F14@delong.com> References: <4F9E9E39.40501@brightok.net> <5558A3D7-18DE-4DB3-BBF2-BF571BB469C2@arin.net> <39044BBA-70FC-4749-8F88-2716857A4F5F@burkov.aha.ru> <68767A02-BBC6-43D2-B62F-947829343038@arin.net> <4FA1DA78.4090401@redbarn.org> <20120503T105531Z@localhost> <4FAC6AC8.9060508@redbarn.org> <20120511T161218Z@localhost> <20120513T020621Z@localhost> <88FC5149-30B0-467A-A07E-89CCFF05E857@delong.com> <13244.1337104840@marajade.sandelman.ca> <26873.1337181076@marajade.sandelman.ca> <504AB22C-864B-4BAC-9928-67E671E78FE2@delong.com> <6ABCC1C0-6DB6-403E-B8D8-78D688CF8F14@delong.com> Message-ID: <20120521123845.AE33F20CFEFF@drugs.dv.isc.org> In message <6ABCC1C0-6DB6-403E-B8D8-78D688CF8F14 at delong.com>, Owen DeLong write s: > > On May 16, 2012, at 10:12 AM, William Herrin wrote: > > > On 5/16/12, Owen DeLong wrote: > >> On May 16, 2012, at 8:11 AM, Michael Richardson wrote: > >>> But, I didn't say it was risk of collision with ULA-R that was the > >>> main problem, it is lack of reverse DNS and lack of whois that is the > >>> problem. > >> > >> Why do you need non-local RDNS and/or WHOIS for local-only addresses? > > > > Hi Owen, > > > > Configuring split-horizon DNS coordinated between multiple > > interconnected organizations has always been a bit of an intractable > > problem, especially when some parts are connected to some other parts > > but not all parts are connected to all other parts. You could > > sometimes get around it with an interior root but DNSSEC blows that > > out of the water. An exterior NS record back to the interior > > authoritative server could potentially help a lot. > > > > Which makes the situation you describe more ideally suited to GUA with > appropriate filtration of routes and packets. > > Owen ULA space is supposed to be within insecure delegation to break the chain of trust, see RFC 6303. Currently isn't which should be corrected. 6. IANA Considerations IANA has established a registry of zones that require this default behaviour. The initial contents of this registry are defined in Section 4. Implementors are encouraged to periodically check this registry and adjust their implementations to reflect changes therein. This registry can be amended through "IETF Review" as per [RFC5226]. As part of this review process, it should be noted that once a zone is added it is effectively added permanently; once an address range starts being configured as a local zone in systems on the Internet, it will be impossible to reverse those changes. IANA should coordinate with the RIRs to ensure that, as DNS Security (DNSSEC) is deployed in the reverse tree, delegations for these zones are made in the manner described in Section 7. 7. Security Considerations During the initial deployment phase, particularly where [RFC1918] addresses are in use, there may be some clients that unexpectedly receive a name error rather than a PTR record. This may cause some service disruption until their recursive nameserver(s) have been re-configured. As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA namespaces, the zones listed above will need to be delegated as insecure delegations, or be within insecure zones. This will allow DNSSEC validation to succeed for queries in these spaces despite not being answered from the delegated servers. It is recommended that sites actively using these namespaces secure them using DNSSEC [RFC4035] by publishing and using DNSSEC trust anchors. This will protect the clients from accidental import of unsigned responses from the Internet. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From hannigan at gmail.com Mon May 21 18:29:43 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 21 May 2012 18:29:43 -0400 Subject: [arin-ppml] Additional modifications to Section 8.3 related to ASN's and legacy addresses Message-ID: Policy Proposal Name: Section 8.3 Modifications: ASN and legacy resources Policy Proposal Name: Inter-RIR Proposal Originator name: Martin Hannigan email: martin at theipv4guy.com telephone: organization: Elected ARIN Advisory Council Member Proposal Version: 1.0 Date: 21 May 2012 Proposal type: NEW Policy term: PERMANENT Policy statement: Change Policy Statement from: 8.3 Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources may be released to ARIN by the authorized resource holder or another RIR, in whole or in part, for transfer to another specified organizational recipient. Organizations in the ARIN region may receive transferred number resources under RSA if they can demonstrate the need for such resources in the amount which they can justify under current ARIN policies. IPv4 address resources may be transferred to organizations in another RIR's service region if they demonstrate need to their region's RIR, according to that RIR's policies. Inter-regional transfers may take place only via RIRs who agree to the transfer and share compatible, needs-based policies. Such resources must be transferred in blocks of /24 or larger and will become part of the resource holdings of the recipient RIR. Change policy statement to: 8.3 Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources and 16 bit ASN's may be released to ARIN by an authorized resource holder or another RIR, in whole or in part, for transfer to another specified organizational recipient. Organizations in the ARIN region may receive transferred IPv4 number resources under RSA if they can demonstrate that the need for such resources exists and in the amount that they can justify under current ARIN policies. IPv4 address resources and 16 bit ASN's may be transferred to organizations in another RIR's service region if they demonstrate need to their region's RIR and compliance with that RIR's policies. IPv4 number resources may be transferred in blocks of the minimum allocation unit of the recipient RIR and will become part of the resource holdings of the recipient RIR. Needs assessments or services agreements with ARIN are not required for legacy resource transfers. ARIN will provide a written and detailed notice that includes the reasons why when refusing any number resource or ASN transfer. This notice will be provided to both parties to the transfer and to the recipient RIR. Rationale: To further increase the utilization of available 16 bit ASN's in order to stimulate 32 bit ASN uptake. The resulting benefit will be realized over (a shorter period of) time as desirable numbers are used from both pools of addresses and software, systems and processes integrate the same to accommodate an eventual compatibility of both pools instead of partial backwards compatibility overall. With regards to the language modifications related to v4 number resources, suggested modifications will pull the stop on the legacy market and make it "more" attractive to utilize the ARIN based transfer system and improve the accuracy of whois data overall. Portions of this proposal would result in greater value to debtors and by creating further support of ARIN policy and confidence in the system. Increasing the level of confidence that a transaction will succeed is "a good thing". Written notice to insure transparency. There are also a few in simple in-context grammatical edits. Note, this is the pre-approved but not yet implemented language vs. the old language. I have confidence 2011-1 is moving forward and this would modify that language. From farmer at umn.edu Mon May 21 19:16:05 2012 From: farmer at umn.edu (David Farmer) Date: Mon, 21 May 2012 18:16:05 -0500 Subject: [arin-ppml] Additional modifications to Section 8.3 related to ASN's and legacy addresses In-Reply-To: References: Message-ID: <4FBACCB5.709@umn.edu> On 5/21/12 5:29 PM, Martin Hannigan wrote: > Needs assessments or services agreements with ARIN are not required > for legacy resource transfers. I cannot this support policy language as it differentiates legacy resources, as someone who works for a legacy resource holder I think this is a really bad idea, the LRSA provides sufficient protections for legacy resource holders. Anyway, it is the resource holder and the resource assignment together that has the legacy classification, once that binding is broken the classification is broken. > ARIN will provide a written and detailed notice that includes the > reasons why when refusing any number resource or ASN transfer. This > notice will be provided to both parties to the transfer and to the > recipient RIR. I have legal concerns about the disclosure to third parties this requires ARIN to make. If the legal concerns can be dealt with, then I think this is probably a good idea, but I think there is lawyer fodder in there. I cannot support this proposal as written. From owen at delong.com Mon May 21 22:44:30 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 21 May 2012 19:44:30 -0700 Subject: [arin-ppml] Additional modifications to Section 8.3 related to ASN's and legacy addresses In-Reply-To: <4FBACCB5.709@umn.edu> References: <4FBACCB5.709@umn.edu> Message-ID: <8E958A18-B610-4450-B43B-5093190DCC95@delong.com> On May 21, 2012, at 4:16 PM, David Farmer wrote: > On 5/21/12 5:29 PM, Martin Hannigan wrote: > >> Needs assessments or services agreements with ARIN are not required >> for legacy resource transfers. > > I cannot this support policy language as it differentiates legacy resources, as someone who works for a legacy resource holder I think this is a really bad idea, the LRSA provides sufficient protections for legacy resource holders. Anyway, it is the resource holder and the resource assignment together that has the legacy classification, once that binding is broken the classification is broken. > Exactly... Resources, once transferred are not legacy resources, so, needs assessment must apply to the recipient or it is begging an immediate section 12- based needs assessment upon completion of the transfer. >> ARIN will provide a written and detailed notice that includes the >> reasons why when refusing any number resource or ASN transfer. This >> notice will be provided to both parties to the transfer and to the >> recipient RIR. > > I have legal concerns about the disclosure to third parties this requires ARIN to make. If the legal concerns can be dealt with, then I think this is probably a good idea, but I think there is lawyer fodder in there. > > I cannot support this proposal as written. +1 -- Do not support. Owen From info at arin.net Tue May 22 10:09:55 2012 From: info at arin.net (ARIN) Date: Tue, 22 May 2012 10:09:55 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - May 2012 Message-ID: <4FBB9E33.10202@arin.net> In accordance with the ARIN Policy Development Process, the ARIN Advisory Council (AC) held a meeting on 17 May 2012 and made decisions about several draft policies and proposals. The AC recommended the following draft policies to the ARIN Board for adoption: ARIN-2012-1: Clarifying requirements for IPv4 transfers ARIN-2012-3: ASN Transfers The following proposals were added to the AC's docket for development and evaluation: ARIN-prop-166 Clarify /29 Assignment Identification Requirement ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers The AC considered the following proposal to be an administrative update: ARIN-prop-169 Cleanup IPv6 section 6.5.7 Regarding proposal 169, "The ARIN AC considers the text removal in this proposal to be administrative, and has asked ARIN staff to work with the BoT to process this change. The text cited for removal is from June 26, 2002. The paragraph that will remain was added to to the September 2011 edition of the NRPM by policy 2011-3. Both pieces of text accomplish similar goals, however the 2002 text is restrictive to early /35 assignments. The 2011-3 text is more generic and will cover any future changes to IPv6 allocation policy." The AC has essentially abandoned proposal 169. Anyone dissatisfied with this decision may initiate a petition. The petition to advance this proposal would be the "Discussion 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 Tue May 22 10:19:20 2012 From: info at arin.net (ARIN) Date: Tue, 22 May 2012 10:19:20 -0400 Subject: [arin-ppml] ARIN-prop-171 Section 8.3 Modifications: ASN and legacy resources In-Reply-To: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> Message-ID: <4FBBA068.8050806@arin.net> ARIN-prop-171 Section 8.3 Modifications: ASN and legacy resources 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-171 Section 8.3 Modifications: ASN and legacy resources Proposal Originator: Martin Hannigan Proposal Version: 1.0 Date: 22 May 2012 Proposal type: NEW Policy term: PERMANENT Policy statement: Change Policy Statement from: 8.3 Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources may be released to ARIN by the authorized resource holder or another RIR, in whole or in part, for transfer to another specified organizational recipient. Organizations in the ARIN region may receive transferred number resources under RSA if they can demonstrate the need for such resources in the amount which they can justify under current ARIN policies. IPv4 address resources may be transferred to organizations in another RIR's service region if they demonstrate need to their region's RIR, according to that RIR's policies. Inter-regional transfers may take place only via RIRs who agree to the transfer and share compatible, needs-based policies. Such resources must be transferred in blocks of /24 or larger and will become part of the resource holdings of the recipient RIR. Change policy statement to: 8.3 Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources and 16 bit ASN's may be released to ARIN by an authorized resource holder or another RIR, in whole or in part, for transfer to another specified organizational recipient. Organizations in the ARIN region may receive transferred IPv4 number resources under RSA if they can demonstrate that the need for such resources exists and in the amount that they can justify under current ARIN policies. IPv4 address resources and 16 bit ASN's may be transferred to organizations in another RIR's service region if they demonstrate need to their region's RIR and compliance with that RIR's policies. IPv4 number resources may be transferred in blocks of the minimum allocation unit of the recipient RIR and will become part of the resource holdings of the recipient RIR. Needs assessments or services agreements with ARIN are not required for legacy resource transfers. ARIN will provide a written and detailed notice that includes the reasons why when refusing any number resource or ASN transfer. This notice will be provided to both parties to the transfer and to the recipient RIR. Rationale: To further increase the utilization of available 16 bit ASN's in order to stimulate 32 bit ASN uptake. The resulting benefit will be realized over (a shorter period of) time as desirable numbers are used from both pools of addresses and software, systems and processes integrate the same to accommodate an eventual compatibility of both pools instead of partial backwards compatibility overall. With regards to the language modifications related to v4 number resources, suggested modifications will pull the stop on the legacy market and make it "more" attractive to utilize the ARIN based transfer system and improve the accuracy of whois data overall. Portions of this proposal would result in greater value to debtors and by creating further support of ARIN policy and confidence in the system. Increasing the level of confidence that a transaction will succeed is "a good thing". Written notice to insure transparency. There are also a few in simple in-context grammatical edits. Note, this is the pre-approved but not yet implemented language vs. the old language. I have confidence 2011-1 is moving forward and this would modify that language. From hannigan at gmail.com Tue May 22 11:25:18 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 22 May 2012 11:25:18 -0400 Subject: [arin-ppml] Additional modifications to Section 8.3 related to ASN's and legacy addresses In-Reply-To: <4FBACCB5.709@umn.edu> References: <4FBACCB5.709@umn.edu> Message-ID: On Mon, May 21, 2012 at 7:16 PM, David Farmer wrote: > On 5/21/12 5:29 PM, Martin Hannigan wrote: > >> Needs assessments or services agreements with ARIN are not required >> for legacy resource transfers. > > > I cannot this support policy language as it differentiates legacy resources, > as someone who works for a legacy resource holder I think this is a really > bad idea, the LRSA provides sufficient protections for legacy resource > holders. ?Anyway, it is the resource holder and the resource assignment > together that has the legacy classification, once that binding is broken the > classification is broken. They are different, that we are sure about. Don't the bankruptcy issues surrounding legacy resources demonstrate that? > > >> ARIN will provide a written and detailed notice that includes the >> reasons why when refusing any number resource or ASN transfer. ?This >> notice will be provided to both parties to the transfer and to the >> recipient RIR. > > > I have legal concerns about the disclosure to third parties this requires > ARIN to make. ?If the legal concerns can be dealt with, then I think this is > probably a good idea, but I think there is lawyer fodder in there. We have a lack transparency with respect to legacy resources and ARIN. I'm open to a "better" way, but expecting ARIN to justify it's actions in writing seems completely reasonable to me. The recipient RIR as a third party overseer seems reasonable as it allows them to monitor compliance. Inter-RIR would seem to imply it's a two way street and the other RIR will have costs. Seems like they should have an idea as to why a transaction they are facilitating may have failed. I think that the lawyers could call this problematic as easily as they could make it workable. > > I cannot support this proposal as written. So those were the only two issues that prevent you from supporting the proposal? From jcurran at arin.net Tue May 22 11:46:39 2012 From: jcurran at arin.net (John Curran) Date: Tue, 22 May 2012 15:46:39 +0000 Subject: [arin-ppml] Additional modifications to Section 8.3 related to ASN's and legacy addresses In-Reply-To: References: <4FBACCB5.709@umn.edu> Message-ID: On May 22, 2012, at 11:25 AM, Martin Hannigan wrote: > They are different, that we are sure about. Don't the bankruptcy > issues surrounding legacy resources demonstrate that? Martin - At present, the same rights and policies are applicable to parties in bankruptcy regardless of whether dealing with resources issued directly by ARIN or by a predecessor registry. There is still a difference in fees but that is that is the predominant difference in the registration service agreements (and there is no difference in the NRPM.) A party in bankruptcy can perform specified transfers IPv4 number resources to another party, and that is available whether they were legacy-issued or otherwise. Note - This does not preclude the ARIN community from adopting policies specific to legacy resources; that is an option if the community feels that such policies would best serve the overall mission of fair & technically sound number resource management. FYI, /John John Curran President and CEO ARIN From bill at herrin.us Tue May 22 12:58:59 2012 From: bill at herrin.us (William Herrin) Date: Tue, 22 May 2012 12:58:59 -0400 Subject: [arin-ppml] Additional modifications to Section 8.3 related to ASN's and legacy addresses In-Reply-To: References: Message-ID: On 5/21/12, Martin Hannigan wrote: > Policy Proposal Name: Section 8.3 Modifications: ASN and legacy resources > > [...] IPv4 number resources may be > transferred in blocks of > the minimum allocation unit of the recipient RIR This language could result in a transfer of blocks smaller than ARIN's minimum, e.g. /28. -Bill -- 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 Tue May 22 14:57:07 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 22 May 2012 14:57:07 -0400 Subject: [arin-ppml] Additional modifications to Section 8.3 related to ASN's and legacy addresses In-Reply-To: References: Message-ID: On Tue, May 22, 2012 at 12:58 PM, William Herrin wrote: > On 5/21/12, Martin Hannigan wrote: >> Policy Proposal Name: Section 8.3 Modifications: ASN and legacy resources >> >> [...] IPv4 number resources may be >> transferred in blocks of >> the minimum allocation unit of the recipient RIR > > This language could result in a transfer of blocks smaller than ARIN's > minimum, e.g. /28. > Yes, especially if recipient RIR's accept them. I'm really not sure that this would be a problem. Best, -M< From hannigan at gmail.com Wed May 23 00:30:12 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 23 May 2012 00:30:12 -0400 Subject: [arin-ppml] Additional modifications to Section 8.3 related to ASN's and legacy addresses In-Reply-To: <4FBACCB5.709@umn.edu> References: <4FBACCB5.709@umn.edu> Message-ID: David, Based on the public and other private feedback, I think a modification as such would be useful. I was trying to maintain the language in the form that it was prior to my modification suggestions, but it is proving to be very difficult to do that and write effective public policy. I'm offering a complete rewrite with a clear delineation between legacy and non-legacy v4 addresses and ASN's. 8.3 Transfers to Specified Recipients 8.3.1 Transfer of non legacy IPv4 and ASN's In addition to transfers under section 8.2, IPv4 number resources and 16 bit ASN's may be released to ARIN by an authorized resource holder or by another RIR, in whole or in part, for transfer to another specified organizational recipient. Organizations in the ARIN region may receive transferred IPv4 number resources under RSA if they can demonstrate that the need for such resources exists and in the amount that they can justify under current ARIN policies. 8.3.2 Transfer of legacy IPv4 addresses and ASN's IPv4 address resources and ASN's may be transferred to organizations in another RIR's service region if they demonstrate need to their region's RIR and compliance with that RIR's policies. IPv4 number resources may be transferred in blocks of the minimum allocation unit of the recipient RIR and will remain the property of the transforee. 8.3.3 Legacy Agreements and Assessments Needs assessments or services agreements with ARIN are not required for legacy resource transfers. In the case of ASN's, a multi homing required is waived for the purpose of transfer. 8.3.4 Notice of Refusal ARIN will provide a written and detailed notice that includes the specific reasons why when refusing any number resource or ASN transfer. This notice will be provided to all parties to a transfer. Rationale: To further increase the utilization of available but unused legacy ASN's in order to stimulate 32 bit ASN uptake. The resulting benefit will be realized over (a shorter period of) time as ASN's are used from both pools of addresses and software, systems and processes integrate the same to accommodate an eventual compatibility of both pools instead of partial backwards compatibility overall. It is recommended that ARIN revisit its own internal assignment policies and allow for the request of specific ASN's from an undifferentiated pool of ASN's in order to create a spread of requests and collateral uptake. With regards to the language modifications related to v4 number resources, suggested modifications will pull the stop on the legacy market and make it "more" attractive to voluntarily adhere to ARIN community established policies as well as increase the reliability of ARIN whois data and ultimately create a more fair and balanced environment for market purchases that includes transparency. This proposal also provides a mechanism for continued drainage of the available v4 pool effectually stimulating uptake in IPv6 as well. Increased uptake of v6 and 32 bit ASN's are both stated objectives of the Internet technical community and are desirable. This proposal would also result in greater value to debtors related to legacy assets in a bankruptcy process by removing uncertainties and unknowns created by vague and unclear policy related to legacy addresses and ASN's. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Wed May 23 00:54:22 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 22 May 2012 21:54:22 -0700 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: <4FBC6D7E.6@rollernet.us> On 4/30/12 8:57 AM, ARIN wrote: > > 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. > I'm a bit late on this, but I oppose. I would not support any proposal that removes the renumbering requirement. If the org is growing enough that they need more than a /24 within a timeframe that it would be "painful" to renumber then they can do the legwork to justify an initial /22 as was the case prior to opening the door to /24's. Or simply accept that the org will either renumber from the /24 like they would renumber from PA anyway and plan ahead. In my opinion, the intent was to open end user PI space to small multihomers. Growing beyond a /24 means you're no longer a "small multihomer" to me. ~Seth From jcurran at arin.net Wed May 23 02:12:20 2012 From: jcurran at arin.net (John Curran) Date: Wed, 23 May 2012 06:12:20 +0000 Subject: [arin-ppml] Additional modifications to Section 8.3 related to ASN's and legacy addresses In-Reply-To: References: <4FBACCB5.709@umn.edu> Message-ID: On May 23, 2012, at 12:30 AM, Martin Hannigan wrote: .3.4 Notice of Refusal ARIN will provide a written and detailed notice that includes the specific reasons why when refusing any number resource or ASN transfer. This notice will be provided to all parties to a transfer. Martin - It is generally the recipient who has difficulty qualifying during a transfer, and while the specific reason is often "Recipient can't demonstrate need in accordance with policy", the proposed language suggests that more detailed information should be returned to both the current resource holder and intended recipient. If that is the case, then it is important to note that this information may contain technical & business planning information of the intended recipient which is only known to ARIN via NDA and therefore not readily releasable. Of course, this may not be as frequent an issue given the legacy aspects of the proposed policy change, but as written, the notice would appear to apply to transfers of any resources and may run afoul of NDA terms unless this disclosure is very clearly specified in the proposed policy, and specifically authorized in advance by intended recipients when applying to transfer resources. Supplying this information to only the recipient would not cause this problem (and we presently do provide that information in the request ticket) but that may not meet your goals for the proposed policy change. FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed May 23 02:12:12 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 22 May 2012 23:12:12 -0700 Subject: [arin-ppml] Additional modifications to Section 8.3 related to ASN's and legacy addresses In-Reply-To: References: <4FBACCB5.709@umn.edu> Message-ID: <11E6E695-AF1F-420E-AD1B-A4AADBE8F4F8@delong.com> On May 22, 2012, at 8:25 AM, Martin Hannigan wrote: > On Mon, May 21, 2012 at 7:16 PM, David Farmer wrote: >> On 5/21/12 5:29 PM, Martin Hannigan wrote: >> >>> Needs assessments or services agreements with ARIN are not required >>> for legacy resource transfers. >> >> >> I cannot this support policy language as it differentiates legacy resources, >> as someone who works for a legacy resource holder I think this is a really >> bad idea, the LRSA provides sufficient protections for legacy resource >> holders. Anyway, it is the resource holder and the resource assignment >> together that has the legacy classification, once that binding is broken the >> classification is broken. > > They are different, that we are sure about. Don't the bankruptcy > issues surrounding legacy resources demonstrate that? > I have no reason to believe that a bankruptcy court would treat non-legacy resources differently from legacy resources. If you have reason to believe that is the case, then, please provide something to back that up. True, all of the bankruptcy related transfers I am aware of have been legacy resources, but, to the best of my knowledge, that is mostly coincidence and not a matter of law. > >> >> >>> ARIN will provide a written and detailed notice that includes the >>> reasons why when refusing any number resource or ASN transfer. This >>> notice will be provided to both parties to the transfer and to the >>> recipient RIR. >> >> >> I have legal concerns about the disclosure to third parties this requires >> ARIN to make. If the legal concerns can be dealt with, then I think this is >> probably a good idea, but I think there is lawyer fodder in there. > > We have a lack transparency with respect to legacy resources and ARIN. Can you be more specific about what is not transparent that needs to be? Owen From hannigan at gmail.com Wed May 23 15:46:24 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 23 May 2012 15:46:24 -0400 Subject: [arin-ppml] Additional modifications to Section 8.3 related to ASN's and legacy addresses In-Reply-To: References: <4FBACCB5.709@umn.edu> Message-ID: John, The intention is to place the communities right to know above the transfer parties right to privacy with respect to legacy number resources and legacy ASN's. It would also be useful for you in order to provide all of us with relevant data as to how a market is operating to the standards we are setting. I know the latter is probably easily accomplished even with confidentiality restrictions in place, but the former is much harder without a policy standard. Is there a better way to do such a thing? In the absence of a needs test for legacy nr/asn's for example, I don't see a lot of need for confidentiality requirements. Thoughts? Best, -M< On Wed, May 23, 2012 at 2:12 AM, John Curran wrote: > On May 23, 2012, at 12:30 AM, Martin Hannigan wrote: > > .3.4 Notice of Refusal > > ARIN will provide a written and detailed notice that includes the > specific reasons why when refusing any number resource or ASN transfer. > ?This > notice will be provided to all parties to a transfer. > > > Martin - > > ? ?It is generally the?recipient who has difficulty qualifying during a > transfer, > ? ?and while the?specific reason is often "Recipient can't demonstrate need > ? ?in accordance?with policy", the proposed language suggests that more > ? ?detailed?information should be returned to both the current resource > holder > ? ?and?intended recipient. ?If that is the case, then it is important to > note that > ? ?this information may?contain technical & business planning information > of > ? ?the intended recipient which is only known to ARIN via NDA and therefore > > ? ?not readily releasable. > > ? ?Of course, this may not be as frequent an issue given the legacy aspects > ? ?of the proposed policy change, but as written, the notice would appear > ? ?to?apply to transfers of any resources and may run afoul of NDA terms > ? ?unless this disclosure is very clearly specified in the proposed policy, > ? ?and?specifically authorized in advance by intended recipients when > ? ?applying to transfer resources. ?Supplying this information to only the > ? ?recipient would not cause this problem (and we presently do provide > ? ?that information in the request ticket) but that may not meet your?goals > ? ?for the proposed policy change. > > FYI, > /John > > John Curran > President and CEO > ARIN > From jcurran at arin.net Wed May 23 16:19:58 2012 From: jcurran at arin.net (John Curran) Date: Wed, 23 May 2012 20:19:58 +0000 Subject: [arin-ppml] Additional modifications to Section 8.3 related to ASN's and legacy addresses In-Reply-To: References: <4FBACCB5.709@umn.edu> Message-ID: On May 23, 2012, at 3:46 PM, Martin Hannigan wrote: > John, > > The intention is to place the communities right to know above the > transfer parties right to privacy with respect to legacy number > resources and legacy ASN's. It would also be useful for you in order > to provide all of us with relevant data as to how a market is > operating to the standards we are setting. I know the latter is > probably easily accomplished even with confidentiality restrictions in > place, but the former is much harder without a policy standard. Is > there a better way to do such a thing? In the absence of a needs test > for legacy nr/asn's for example, I don't see a lot of need for > confidentiality requirements. Martin - Implementing the policy proposal as written is quite possible, but I wanted to highlight that providing this information to the recipient happens presently and the recipient who does not qualify has ability to share this information with current holder as desired (or if required by any agreement between the parties.) ARIN providing this information directly to the current address holder may require us sharing information about the applicant which is highly sensitive and to do so at the exact moment that applicant/intended recipient and current address holder are potentially ending their relationship. ARIN providing this information only the applicant/intended recipient and having the intended recipient keep everyone in the pending transaction informed because its required per their transaction document would be administratively easier and not having ARIN providing one party's detailed network information to another. I do not know, however, if that approach meets your policy goals; it may not be an effective option depending on the problem you're trying to address. Thanks! /John John Curran President and CEO ARIN From hannigan at gmail.com Wed May 23 17:39:31 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 23 May 2012 17:39:31 -0400 Subject: [arin-ppml] Additional modifications to Section 8.3 related to ASN's and legacy addresses In-Reply-To: References: <4FBACCB5.709@umn.edu> Message-ID: On Wed, May 23, 2012 at 4:19 PM, John Curran wrote: > On May 23, 2012, at 3:46 PM, Martin Hannigan wrote: > >> John, >> >> The intention is to place the communities right to know above the >> transfer parties right to privacy with respect to legacy number >> resources and legacy ASN's. It would also be useful for you in order >> to provide all of us with relevant data as to how a market is >> operating to the standards we are setting. I know the latter is >> probably easily accomplished even with confidentiality restrictions in >> place, but the former is much harder without a policy standard. Is >> there a better way to do such a thing? In the absence of a needs test >> for legacy nr/asn's for example, I don't see a lot of need for >> confidentiality requirements. > > Martin - > > ?Implementing the policy proposal as written is quite possible, > ?but I wanted to highlight that providing this information to > ?the recipient happens presently and the recipient who does not > ?qualify has ability to share this information with current holder > ?as desired (or if required by any agreement between the parties.) > > ?ARIN providing this information directly to the current address > ?holder may require us sharing information about the applicant > ?which is highly sensitive and to do so at the exact moment that > ?applicant/intended recipient and current address holder are > ?potentially ending their relationship. > > ?ARIN providing this information only the applicant/intended > ?recipient and having the intended recipient keep everyone in > ?the pending transaction informed because its required per their > ?transaction document would be administratively easier and not > ?having ARIN providing one party's detailed network information > ?to another. ?I do not know, however, if that approach meets your > ?policy goals; it may not be an effective option depending on the > ?problem you're trying to address. > John, Thanks. I'm going to take a different track on this based on your feedback and others. Separating 8.3 from the discussion and leaving it intact will allow us to focus on [8.4] a non-legacy discussion which may turn out to be simpler overall. Best, -M< From info at arin.net Wed May 23 17:56:57 2012 From: info at arin.net (ARIN) Date: Wed, 23 May 2012 17:56:57 -0400 Subject: [arin-ppml] ARIN-prop-171 Section 8.4 Modifications: ASN and legacy resources In-Reply-To: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> Message-ID: <4FBD5D29.2070403@arin.net> ARIN-prop-171 Section 8.4 Modifications: ASN and legacy resources The proposal originator revised the proposal. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-171 Section 8.4 Modifications: ASN and legacy resources Proposal Originator: Martin Hannigan Proposal Version: 2 Date: 23 May 2012 Policy statement: 8.4 Transfers of Legacy Resources to Specified Recipients 8.4.1 Legacy Number Resource and ASN Transfers Legacy IPv4 number resources and ASN's may be transferred to organizations in any RIR's service region. 8.4.2 Minimum Transfer Size Legacy IPv4 number resources and ASN's may be transferred in blocks of the minimum allocation unit of the recipient RIR. 8.4.3 Needs Assessments and Utilization Requirements Needs assessments and utilization requirements for legacy number resources and ASN's are waived. 8.4.4 Registry Services ARIN will insure that all parties to a legacy number resource or ASN transfer agree to provide and maintain accurate WHOIS contact data in compliance with WHOIS policy. Transfers shall not be completed until all submitted WHOIS update data has been verified as accurate. 8.4.5. Chain of Custody Validation No resources may be transferred without a verifiable chain of custody demonstrating that a party desiring to transfer a resource is the legitimate holder of such a resource and is eligible to transfer the resource. Upon confirmation of a valid chain of custody of a resource, ARIN will certify that resource as transferable. ARIN will maintain this certification on file for future reference. 8.4.6 Flawed Custody and Fraudulent Applications ARIN may reclaim legacy resources that fail chain of custody certifications or are deemed fraudulently obtained at it's discretion. Rationale: The ARIN region has a large pool of legacy number resources and ASN's that most agree is causing the pace of IPv6 adoption to under-perform. Providing a means through policy to exhaust these pools "should" stimulate the adoption of IPv6. The language for non legacy address and ASN transfers is unaffected in this proposal. The proposal seeks to set clear and written standards for both the legacy and non legacy number resource and ASN transfer function along a recognized boundary. Standard setting will have a desirable technically oriented result that would benefit the community by moving us closer to a) full compatibility of 16 and 32 bit ASN's b) bringing the legacy trading market entirely above board c) providing standards for them to operate by and d) providing for full transparency and accountability to the community. Requiring a chain of custody validation as part of the process will hopefully discourage unauthorized transferors from wasting the effort and capital of legitimate transferees and identify resources that are potentially available for reclamation. The whois requirements are a small price to pay for the ability to transfer a legacy resource. It should also be noted that no party is prevented from signing an LRSA or RSA if they so desire. It is recognized that this is a fairly interesting piece of policy that would benefit tremendously from legal and staff review. From springer at inlandnet.com Wed May 23 21:36:28 2012 From: springer at inlandnet.com (John Springer) Date: Wed, 23 May 2012 18:36:28 -0700 (PDT) Subject: [arin-ppml] ARIN-prop-171 Section 8.4 Modifications: ASN and legacy resources In-Reply-To: <4FBD5D29.2070403@arin.net> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FBD5D29.2070403@arin.net> Message-ID: <20120523150900.M66878@mail.inlandnet.com> On Wed, 23 May 2012, ARIN wrote: > ARIN-prop-171 Section 8.4 Modifications: ASN and legacy resources > > It is recognized that this is a fairly interesting piece of policy > that would benefit tremendously from legal and staff review. > _______________________________________________ > PPML On first pass, I'm still digesting but the above seems ahead of events. I'm being picky but this is after all the first presentation of a new version (2) of a proposal and not a "piece of policy". The "It is recognized" part in particular is weird. Using expressions of interest in the previous rather different version as constituting recognition of the merits of the present document, from within the document presenting the new proposal for the first time is overreaching. Although maybe someone other than the author can recognize it as interesting and make the point moot. All proposals benefit from review from legal and staff if they get far enough in the PDP, and from the PPML, regardless of how far they get. Changing the point of legal/staff engagement seems out of scope for the proposal. Good sales technique though. :) John Springer From hannigan at gmail.com Wed May 23 22:30:13 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 23 May 2012 22:30:13 -0400 Subject: [arin-ppml] ARIN-prop-171 Section 8.4 Modifications: ASN and legacy resources In-Reply-To: <20120523150900.M66878@mail.inlandnet.com> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4FBD5D29.2070403@arin.net> <20120523150900.M66878@mail.inlandnet.com> Message-ID: On Wed, May 23, 2012 at 9:36 PM, John Springer wrote: > On Wed, 23 May 2012, ARIN wrote: > >> ARIN-prop-171 Section 8.4 Modifications: ASN and legacy resources >> >> It is recognized that this is a fairly interesting piece of policy >> that would benefit tremendously from legal and staff review. >> _______________________________________________ >> PPML > > > On first pass, I'm still digesting but the above seems ahead of events. I'm > being picky but this is after all the first presentation of a new version > (2) of a proposal and not a "piece of policy". > > The "It is recognized" part in particular is weird. Using expressions of Not at all. And yes, perhaps a bit picky. It's intended as a slight touch of humor for a most serious policy proposal. > Good sales technique though. :) Thanks! Best, -M< From narten at us.ibm.com Fri May 25 00:53:03 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 25 May 2012 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201205250453.q4P4r314030291@rotala.raleigh.ibm.com> Total of 27 messages in the last 7 days. script run at: Fri May 25 00:53:03 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 25.93% | 7 | 27.96% | 55657 | hannigan at gmail.com 14.81% | 4 | 15.96% | 31774 | jcurran at arin.net 14.81% | 4 | 15.29% | 30443 | info at arin.net 7.41% | 2 | 6.88% | 13707 | owen at delong.com 7.41% | 2 | 5.85% | 11644 | micah at riseup.net 3.70% | 1 | 4.88% | 9713 | marka at isc.org 3.70% | 1 | 3.82% | 7613 | jmaimon at chl.com 3.70% | 1 | 3.77% | 7508 | narten at us.ibm.com 3.70% | 1 | 3.43% | 6819 | farmer at umn.edu 3.70% | 1 | 3.19% | 6353 | cgrundemann at gmail.com 3.70% | 1 | 3.15% | 6280 | sethm at rollernet.us 3.70% | 1 | 2.93% | 5842 | springer at inlandnet.com 3.70% | 1 | 2.88% | 5732 | bill at herrin.us --------+------+--------+----------+------------------------ 100.00% | 27 |100.00% | 199085 | Total From info at arin.net Thu May 31 11:01:22 2012 From: info at arin.net (ARIN) Date: Thu, 31 May 2012 11:01:22 -0400 Subject: [arin-ppml] Fwd: Proposed Revision to the ARIN Policy Development Process In-Reply-To: <4FC51D9C.5050606@arin.net> References: <4FC51D9C.5050606@arin.net> Message-ID: <4FC787C2.6000601@arin.net> ARIN has opened a consultation on the Consultations mailing list regarding the Revised Policy Development Process (PDP). Please provide comments to arin-consult at arin.net. You can subscribe to this mailing list at: http://lists.arin.net/mailman/listinfo/arin-consult. Discussion on arin-consult at arin.net will close on 28 June 2012. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) -------- Original Message -------- Subject: Proposed Revision to the ARIN Policy Development Process Date: Tue, 29 May 2012 15:03:56 -0400 From: ARIN To: arin-consult at arin.net ARIN is consulting with the community in regards to the attached revised Policy Development Process (PDP) for Internet number resource policy development in the ARIN region. Significant changes in this revision of the PDP include: - Improved definition of the scope of the PDP process - Clarified principles for good number resource policy, i.e. it is fair/impartial, technically sound, and has the support of the community - Clarified Board criteria for ratification of developed policies - Added a role for the ARIN Advisory Council (AC) to perform an initial review of each new policy proposal to confirm that it is clear and in scope of the PDP - Changed the process so all clear, in-scope policy proposals become draft policies upon successful initial review - Added requirement for the AC to provide a full explanation of any policy action taken - One petition per policy action; if successful, petitioners mutually select the presenter of the draft policy at PPM There are three parts: Part One is the goals of the PDP, Part Two is the PDP itself, and Part Three is the PDP Petition Process. The initial consultation posting, including a link to the text of the revised Policy Development Process and a flowchart are available at: https://www.arin.net/participate/acsp/community_consult/05-29-2012_pdp.html Please provide comments to arin-consult at arin.net. You can subscribe to this mailing list at: http://lists.arin.net/mailman/listinfo/arin-consult. Discussion on arin-consult at arin.net will close on 28 June 2012 (30 days). ARIN seeks clear direction through community input, so your feedback is important. If you have any questions, please contact us at info at arin.net. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## PART ONE ? ARIN POLICY DEVELOPMENT PROCESS GOALS 1. Purpose This document describes the ARIN Policy Development Process (PDP). The ARIN PDP is the process by which policies for the management of Internet number resources in the ARIN region are developed by the community. These Internet number resource policies are developed in an open and transparent manner that allows anyone to participate in the process. The PDP is designed to bring forth clear, technically sound and useful policies for ARIN to use in the management and administration of Internet number resources. To accomplish this goal, the PDP charges the community-elected ARIN Advisory Council (AC) as the primary policy development body with appropriate checks and balances on its performance in that role. Part One of this document provides the underlying goals for the Policy Development Process (including its purpose, scope, principles, and criteria for policy changes) and Part Two details the specific Policy Development Process used for development of changes to Internet number resource policy. Part Three details the processes for petitioning specific aspects of the Policy Development Process. 2. Definitions Internet Number Resources Internet number resources consist of Internet Protocol version 4 (IPv4) address space, Internet Protocol version 6 (IPv6) address space, and Autonomous System (AS) numbers. Policy Proposal An idea for a policy that is submitted to the Policy Development Process. Members of the ARIN Advisory Council and ARIN staff work with the originator to refine the Policy Proposal so that it contains a clear statement of the existing problem with Internet number resource policy and suggested changes to Internet number resource policy text to address the problem. In cooperation with ARIN staff, the ARIN AC also confirms each Policy Proposal is within scope (per Section 3) of the Policy Development Process. Draft Policy A Policy Proposal that is complete and in scope for the PDP is accepted by the Advisory Council and becomes a Draft Policy. The Advisory Council further develops the Draft Policy, working in cooperation with the policy originator if available. A Draft Policy, once fully developed, consists of a clear problem statement, proposed changes to number resource policy text, and an assessment of the conformance of the Draft Policy to ARIN?s Principles of Internet Number Resource Policy (as specified in Part One, Section 4 of the Policy Development Process.) Recommended Draft Policy A Recommended Draft Policy is the result of a Draft Policy being fully developed (containing clear problem statement, proposed changes to policy text, and an assessment of conformance to the PDP principles) and then being recommended for adoption by action of the ARIN Advisory Council. A Draft Policy becomes a Recommended Draft Policy once the Advisory Council believes with a high likelihood that the Draft Policy satisfies ARIN?s Principles of Internet Number Resource Policy. Recommended Draft Policies must undergo community consultation and a ?Last Call? period before being considered for adoption. Adopted Policy A policy that has been adopted by the ARIN Board of Trustees. Adopted Policies are incorporated into ARIN?s Number Resource Policy Manual (NRPM) as of their effective date. Public Policy Mailing List (PPML) The ARIN public mailing list for discussion of Internet number resource policy. Public Policy Consultation (PPC) An open public discussion held by ARIN of Internet number resource policy that provides for the contemporaneous interaction and polling of in-person and remote participants. These consultations may be held at ARIN?s Public Policy Meetings and at other related forums as approved by the ARIN Board of Trustees. Public Policy Meeting (PPM) A public forum held periodically by ARIN that includes Public Policy Consultations of all Draft and Recommended Draft Policies. Public Policy Meetings are held at least annually, although Public Policy Consultations for individual draft policies may be held in between Public Policy Meetings in similar open forums. Petition An action initiated by any member of the community (including a proposal originator) if they are dissatisfied with the action taken by the Advisory Council regarding a specific Policy Proposal, Draft Policy or Recommended Draft Policy. 3. Scope of Internet Number Resource Policies 3.1. Policies, not Processes, Fees, or Services Internet number resource policies developed through the PDP describe the policies and guidelines to be followed in number resource management, not the procedures that ARIN staff will use to implement the policies. ARIN staff develops appropriate procedures to implement policies after they are adopted. Internet number resource policies are also distinctly separate from ARIN general business practices. ARIN's general business processes, fees, and services are not within the purview of the Policy Development Process, and while policies developed through the PDP may apply to ARIN?s service offering, they cannot define or establish ARIN fees or service offerings. All matters concerning fees and service offerings are part of the fiduciary responsibility of the Board of Trustees. Note that the ARIN Consultation and Suggestion Process (ARIN ACSP) may be used to propose changes in non-policy areas. Changes to policy that are purely editorial in nature are beyond the scope of the Policy Development Process and may only be made with the concurrence of both the ARIN Advisory Council and ARIN Board of Trustees regarding their non-substantial nature. 3.2. Relevant and Applicable within the ARIN Region Policies developed through the PDP are community self-regulatory statements that govern ARIN?s actions in the management of Internet number resources. Policy statements must be applicable to some portion of the community for number resources managed within the ARIN region, and proposals to change policy must address a clearly defined, existing or potential problem with number resource policy in the region. Note that the Policy Development Process for global policies follows a similar process within each RIR region with the additional process of ratification by the Internet Corporation for Assigned Names and Numbers (ICANN). The Global Policy Development Process is separately documented and facilitated by the Address Supporting Organization Address Council (ASO AC), and in these circumstances, the ARIN PDP is also used in the development of number resource policies with global applicability. 4. Principles of Internet Number Resource Policy Internet number resource policy must satisfy three important principles, specifically: 1) enabling fair and impartial number resource administration, 2) technically sound (providing for uniqueness and usability of number resources), and 3) supported by the community. 4.1. Enabling Fair and Impartial Number Resource Administration Internet number resources must be managed with appropriate stewardship and care. Internet number resource policy must provide for fair and impartial management of resources according to unambiguous guidelines and criteria. All policy statements must be clear, complete, and concise, and any criteria that are defined in policy must be simple and obtainable. Policy statements must be unambiguous and not subject to varying degrees of interpretation. 4.2. Technically Sound Policies for Internet number resources management must be evaluated for soundness against three overarching technical requirements: conservation, aggregation and registration. More specifically, policies for managing Internet number resources must: ? Support both conservation and efficient utilization of Internet number resources to the extent feasible. Policy should maximize number resource availability to parties with operational need. ? Support the aggregation of Internet number resources in a hierarchical manner to the extent feasible. Policy should permit the routing scalability that is necessary for continued Internet growth. (Note that neither ARIN, nor its policies, can guarantee routability of any particular Internet number resource as that is dependent on the actions of the individual Internet operators.) ? Support the unique registration of Internet number resources. Policy should prevent to the extent feasible any unknown or duplicate use of Internet number resources that could disrupt Internet communications. Policies must achieve a technically sound balance of these requirements, and support for these technical requirements must be documented in the assessment of the policy change. 4.3. Supported by the Community Changes to policy must be shown to have a strong level of support in the community in order to be adopted. The determination of support is most commonly done via consideration at a Public Policy Consultation (PPC) or via online poll after discussion on the Public Policy Mailing List (PPML). The Policy Development Process, as a consensus-based collaborative development process, encourages incorporation of feedback received from participants where possible with the goal of increasing community support for policy changes. A strong level of community support for a policy change does not mean unanimous; it may be demonstrated by a subset of the community, as long as the policy change enjoys substantially more support than opposition in the community active in the discussion. 5. ARIN Board of Trustees Criteria for Policy Changes In order to maintain fidelity to the duty performed by ARIN on behalf of the Internet community, changes to Internet number resource policy must meet two specific criteria before being adopted by the ARIN Board of Trustees: 1) in compliance with law and ARIN?s mission, and 2) developed via open and transparent processes. 5.1. In Compliance with Law and ARIN?s Mission Policies developed through the PDP must advance ARIN?s mission, not create unreasonable fiduciary or liability risk, and must be consistent with ARIN's Articles of Incorporation, Bylaws, and all applicable laws and regulations. 5.2. Developed by Open& Transparent Processes Changes to policy must be developed via open and transparent processes that provide for participation by all. Policies must be considered in an open, publicly accessible forum as part of the adoption process. Policy discussions in the ARIN region are conducted on the Public Policy Mail List (PPML) and via Public Policy Consultation (PPC). There are no requirements for participation other than adherence to the guidelines of behavior and decorum, and anyone interested in following the process may subscribe to the PPML or may attend a PPC in person or via remote participation methods. All aspects of the PDP are documented and publicly available via the ARIN website. The PPML is archived. The proceedings of each PPM are published. All policies are documented in the Number Resource Policy Manual (NRPM). All Draft Policies are cross referenced to the original Policy Proposal, the archives of the PPML, all related PPC proceedings, and the minutes of the appropriate Advisory Council and the ARIN Board of Trustees meetings. The procedures that are developed to implement the policy are documented, publicly available, and followed by the ARIN staff. The Policy Development Process itself may only be changed by the ARIN Board of Trustees after a public consultation period to consider the proposed changes. PART TWO ? THE POLICY DEVELOPMENT PROCESS This section provides the details of the ARIN Policy Development Process. A graphical flow depiction of the process is provided at Appendix A. All references to ?days? are calendar days. All ARIN Advisory Council decisions on policy matters require an affirmative roll call vote of the majority of the members of the full Advisory Council, unless otherwise specified. 1. The Policy Proposal Policy Proposals may be submitted to the ARIN Policy Development Process by anyone in the global Internet community except for members of the ARIN Board of Trustees or the ARIN staff. Policy Proposals may be submitted any time by sending them to policy at arin.net. Upon recipient of a new Policy Proposal, the ARIN staff assigns it a Policy Proposal number, posts the Policy Proposal to the public web site, and notifies the Advisory Council of a new Policy Proposal available for consideration. The Advisory Council designates one or more members to work with the policy originator as needed. The assigned AC members and ARIN staff will work with the originator as described below to prepare the Policy Proposal for evaluation by the Advisory Council. The assigned members of the Advisory Council work with the proposal originator by providing feedback regarding the clarity and understanding of the Policy Proposal. The merits of the Policy Proposal itself are not considered at this time; the Policy Proposal is revised as needed so that it contains a clear statement of the problem with existing Internet number resource policy, that any suggested changes to Internet number resource policy text are understandable to the ARIN staff and community, and to identify and correct any potential scope considerations of the Policy Proposal. The proposal originator may revise (or not) the Policy Proposal based on the feedback received. Once the originator and assigned members of the Advisory Council are satisfied with the scope and clarity of the Policy Proposal, it is evaluated by the Advisory Council. 2. Policy Proposal Evaluation During Policy Proposal evaluation, the Advisory Council does not evaluate the merits of Policy Proposal other than to confirm that the Policy Proposal is within scope of the Policy Development Process and contains a clear statement of the problem and suggested changes to number resource policy text. Upon submission to the Advisory Council (AC), each Policy Proposal is evaluated in a timely manner to determine if the Policy Proposal is within scope of the Policy Development Process. Policy Proposals which are determined by the Advisory Council to be out of scope (e.g. for not addressing a clearly defined existing or expected problem, or that propose solutions involving other than number resource policy in the region) are rejected at this point, and the Advisory Council announces the rejection of a Policy Proposal along with an explanation of its reasoning on the ARIN Public Policy Mailing List (PPML). The Advisory Council also evaluates whether the Policy Proposal contains a clear statement of the existing problem with Internet number resource policy including suggested changes to number resource policy text to address the problem. Once this has been confirmed, the Advisory Council accepts it as a Draft Policy for further development work with the community. The Advisory Council announces the acceptance of a Policy Proposal as a Draft Policy on the ARIN Public Policy Mailing List (PPML) and encourages community discussion of its merits and concerns. Policy Proposals that are determined by the Advisory Council to lack clarity are remanded back to the originator along with an explanation of the areas needing improvements in clarity. The proposal originator revises the Policy Proposal based on the feedback received, and again offers the revised Policy Proposal for evaluation by the Advisory Council. The Advisory Council maintains a docket of all Policy Proposals. A submitted Policy Proposal that is not rejected upon evaluation as being out of scope remains on the docket as a Policy Proposal until it is withdrawn by originator or accepted by the Advisory Council as a Draft Policy. Remanded Policy Proposals that are not revised by the originator within 60 days are deemed abandoned. 3. Draft Policy Discussion and Development The Advisory Council is responsible for the development of policies to meet ARIN?s Principles of Internet Number Resource Policy (as described in Part One, Section 4). The Advisory Council maintains a docket of all Draft Policies. As part of the policy development effort, the Advisory Council participates in and encourages the discussion of the Draft Policies on the PPML, notes the merits and concerns raised, and then based on its understanding of the relevant issues, the Advisory Council may take various actions including abandoning, revising or merging the Draft Policy with other Draft Policies. To the extent that the policy originators are available and responsive, the Advisory Council includes them in the revision process. The Advisory Council may submit a Draft Policy at any time for a combined staff and legal review (and should do so after significant revisions to a Draft Policy). This review will be completed within 14 days. Upon receipt of the staff and legal review comments, the Advisory Council examines the comments to ensure their understanding and resolve any issues that may have been raised. The Advisory Council announces any actions taken on Draft Policies along with an explanation of its reasoning on the PPML. 4. Recommendation of Draft Policies The Advisory Council develops and refines Draft Policies until they are satisfied that the Draft Policy meets ARIN?s Principles of Internet Number Resource Policy (Part One, Section 4). Specifically, these principles are: ? Enabling Fair and Impartial Number Resource Administration ? Technically Sound ? Supported by the Community Guided by the discussion of the Draft Policy on the PPML, Public Policy Consultations with the community (if any) and its best judgment, the Advisory Council assesses the conformance of each Draft Policy to these principles and documents the result in an assessment section within the Draft Policy. Any specific concerns expressed by a significant portion of the community must be explicitly noted and addressed in the assessment of the policy change. Once a Draft Policy is fully developed and the Advisory Council is satisfied that it meets the principles of Internet number resource policy (including the support of the community based on online discussion that has occurred thus far), the Advisory Council recommends the Draft Policy for adoption. Recommended Draft Policies must undergo community consultation before proceeding to Last Call and being sent for consideration by the ARIN Board of Trustees. 5. Community Consultation and Public Policy Meetings ARIN holds periodic Public Policy Meetings (PPM) where the Advisory Council reports on the status of all Draft Policies and Recommended Draft Policies on its docket for discussion and feedback from the community. The presentation and discussion is referred to as a ?Public Policy Consultation?. Recommended Draft Policies may not be changed in the 30 days prior to its Public Policy Consultation. As each Draft Policy is presented for Public Policy Consultation, members of the Advisory Council will provide the arguments for and against adoption (petitioned items are handled per PDP Part Three: Petition Process). The Advisory Council participates in the discussion during the Public Policy Consultation, and notes significant merits and concerns that were raised in the discussion for inclusion in the policy assessment. Based on the feedback received and its best judgment, the Advisory Council revises the Draft Policy to address concerns raised where it will improve the overall community support for the policy change. Within the 60 days following a Public Policy Consultation on a Recommended Draft Policy, the Advisory Council reviews the result of the discussion (including any polls of support) and decides the appropriate next action. 6. Confirming Community Support for Recommended Draft Policies The Advisory Council confirms community support for Recommended Draft Policies, and this support may be ascertained by a show of hands during a Public Policy Consultation. The Advisory Council should carefully weigh the community support shown for a Recommended Draft Policy. Absence of clear community support is a strong indication that policy abandonment should be considered. A low level of overall support without opposition for a Recommended Draft Policy suggests further discussion of the merits of the policy change or abandonment. A clear split in the community support suggests that the Advisory Council should revise the Recommended Draft Policy to accommodate the concerns raised or further explain its consideration of the matter. A Recommended Draft Policy that has demonstrated clear support (and only relatively low opposition for well-understood reasons) may be advanced to Last Call by the Advisory Council within 60 days of its Public Policy Consultation. All Recommended Draft Policies not advanced to Last Call within 60 days of completion of their Public Policy Consultation will revert to Draft Policy status. 7. Last Call The Advisory Council advances Recommended Draft Policies with clear support to Last Call. Last Call provides an opportunity for final review by the community via discussion on the PPML. The last call period will be for a minimum of 14 days. The Advisory Council may decide that certain Recommended Draft Policies require a longer last call period of review (such as those that were revised based on comments received during Public Policy Consultation). If the Advisory Council sends a Recommended Draft Policy different than the Recommended Draft Policy presented during the Public Policy Consultation, then the Advisory Council will provide a detailed explanation for all changes to the text and these specific changes must have been discussed during the community consultation at the Public Policy Meeting. The Advisory Council will review the results of the Last Call discussion, and will determine if they still recommend adoption by the ARIN Board of Trustees. The Advisory Council may make minor editorial changes to a Recommended Draft Policy and reissue it for Last Call. No other changes may be made while the policy is in Last Call. A Recommended Draft Policy that has undergone a successful Last Call discussion may be sent to the ARIN Board of Trustees for adoption consideration. Decisions to send Recommended Draft Policies to the ARIN Board shall be made by the affirmative roll call vote of the two thirds of the members of the full Advisory Council. The results of the Advisory Council's decisions, and the reasons for them, are announced on the PPML. All recommended policies not sent to the ARIN Board of Trustees for consideration within 60 days of Last Call completion will revert to Draft Policy status. 8. Board of Trustees Review The ARIN Board of Trustees evaluates a Recommended Draft Policy for adoption once it is received from the Advisory Council. In its review, the Board of Trustees evaluates the policy with respect to the Policy Development Goals of the PDP including specifically whether the ARIN Policy Development Process has been followed, and whether the policy is in compliance with law and ARIN?s mission. The Board of Trustees may adopt, reject or remand Recommended Draft Policies to the Advisory Council. All rejections will include an explanation. Remands will explain the need for further development. The Board of Trustees may also seek clarification from the Advisory Council without remanding the recommended policy. The results of the Board of Trustees? decision are announced on the ARIN Public Policy Mailing List (PPML). 9. Implementation The projected implementation date of the policy is announced at the time that adoption of the policy is announced. ARIN staff updates the Number Resource Policy Manual (NRPM) to include the adopted policy and implements and publishes a new version of the manual. 10. Special Policy Actions 10.1 Emergency PDP If urgently necessary pursuant to ARIN?s mission, the Board of Trustees may initiate policy by declaring an emergency and posting a Recommended Draft Policy on the PPML for discussion for a minimum of 14 days. The Advisory Council will review the Recommended Draft Policy within 7 days of the end of the discussion period and make a recommendation to the Board of Trustees. If the Board of Trustees adopts the policy, it will be presented at the next Public Policy Meeting for reconsideration. 10.2 Policy Suspension If, after a policy has been adopted, the Board receives credible information that a policy is flawed in such a way that it may cause significant problems if it continues to be followed, the Board of Trustees may suspend the policy and request a recommendation from the Advisory Council on how to proceed. The recommendation of the Advisory Council will be published for discussion on the PPML for a period of at least 14 days. The Board of Trustees will review the Advisory Council's recommendation and the PPML discussion. If suspended, the policy will be presented at the next scheduled Public Policy Meeting in accordance with the procedures outlined in this document. PART THREE ? PDP PETITION PROCESS This section provides the details of the petitions within the Policy Development Process. Petitions can be made at points where decisions are made in the policy process. Points where petitions are available are depicted on the main PDP flow diagram in Appendix A. All ?days? in the process below are calendar days. 1. Petition Principles 1.1 Available to the community Any member of the community may initiate a petition if they are dissatisfied with a specific action taken by the ARIN Advisory Council (AC) regarding a Policy Proposal, Draft Policy or Recommended Draft Policy. The petitioner does not have to be located in the ARIN region or associated with an organization that is a Member of ARIN; any party (including a Policy Proposal originator) with interest in policy development matters within the ARIN region may initiate a petition. Notwithstanding the above, ARIN Staff and ARIN Board of Trustees members may not initiate or be counted in support of petitions as these individuals already have a formally defined role in the Policy Development Process. 1.2 Petition Initiation and Process A petition may be initiated by sending an email message to the ARIN Public Policy Mailing List (PPML) clearly requesting a petition against a specific action as listed below and including a statement to the community on why the petition is warranted. ARIN Staff will confirm the validity of the petition and then announce the start of the petition period on the PPML mailing list. Until the close of the petition period, members of the community (as allowed to petition per 1.1 above) may be counted in support for an existing petition by sending an email message to the PPML clearly stating their support for the petition. Only one petition will be considered for a given policy action; all subsequent requests to petition for the same action within the petition period shall be considered as support for the original petition. The petition shall remain open for 5 days, at which time the ARIN Staff shall determine if the petition succeeds (a successful petition requires expressions of petition support from at least 10 different people from 10 different organizations unless otherwise specified.) A successful petition will result in a change of status for the Policy Proposal or Draft Policy as specified below. Staff and legal reviews will be conducted and published for Draft Policies that result from successful petitions. Successfully petitioned Draft Policies are presented for Public Policy Consultation at the next Public Policy Meeting by an individual chosen by the petition supporters, with preference given to the proposal originator. If consensus is not achieved in determining the presenter, then the President may facilitate the selection process. 2. Valid Petitions Petitions may be made regarding specific actions against Policy Proposals, Draft Policies, and Recommended Draft Policies as described below. 2.1. Petition against Abandonment or Rejection due to Out of Scope The Advisory Council?s decision to abandon a Policy Proposal, Draft Policy or Recommended Draft Policy may be petitioned. Petitions may be initiated within the 5 days following the announcement date of an Advisory Council abandonment of a specific Policy Proposal or any Draft Policy. For sake of clarity, the ?announcement date? of an action shall be the publication date of the action in the ARIN AC draft minutes. Additionally, Policy Proposals that have not been accepted as a Draft Policy after 90 days may also be considered abandoned and petitioned to Draft Policy status at anytime. For a Policy Proposal that has been rejected due to being out of scope of the PDP, a successful petition will refer the question of whether the Policy Proposal is in scope to the ARIN Board of Trustees for consideration. For a petition against Draft Policy or Recommended Draft Policy abandonment, a successful petition will result in the Draft Policy being placed back on the Advisory Council docket under control of the petitioner and scheduled for public policy consultation at the next PPM. After the public consultation, control returns to the Advisory Council and subsequently may be revised or abandoned per the normal Policy Development Process. 2.2. Petition for Recommended Status Any member of the community may initiate a Petition for Recommended Status if they believe that a Draft Policy (either the original version as proposed or the current version) is fully developed to meet the requirements of Recommended Draft Policy, and the Advisory Council has not advanced the Draft Policy to Recommended Draft Policy status after 90 days as a Draft Policy. A successful petition for Recommended Status requires expressions of petition support from at least 15 different people from 15 different organizations. If successful, the petition will result in the Draft Policy being put under control of the petitioner, advanced to Recommended Draft status, and scheduled for public policy consultation at the next PPM. The resulting Recommended Draft Policy shall be under control of the Advisory Council after the public policy consultation and subsequently may be revised or abandoned per the normal Policy Development Process. 2.3. Petition for Last Call Any member of the community may initiate a Last Call Petition if they are dissatisfied with the Advisory Council?s failure to act within the allotted time (60 days) to advance a Recommended Draft Policy to last call. A successful Petition for Last Call requires expressions of petition support from at least 20 different people from 20 different organizations. If successful, the petition will move the Recommended Draft Policy as presented during its Public Policy Consultation to last call discussion and review by the community on the PPML. The Recommended Draft Policy shall be under the control of the Advisory Council after Last Call. 2.4. Petition for Board of Trustees Consideration Any member of the community may initiate a Board of Trustees Consideration Petition if they are dissatisfied with the Advisory Council?s failure to act within the allotted time (60 days) to send a Recommended Draft Policy in last call to the Board of Trustees for consideration. A successful petition for Board of Trustees Consideration requires expressions of petition support from at least 25 different people from 25 different organizations. If successful, this petition will send the Recommended Draft Policy from last call to the Board of Trustees for consideration. Appendix A - Draft PDP Flowchart The draft PDP text and flowchart are available at: https://www.arin.net/policy/pdp_proposed.html From info at arin.net Thu May 31 16:29:44 2012 From: info at arin.net (ARIN) Date: Thu, 31 May 2012 16:29:44 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - May 2012 In-Reply-To: <4FBB9E33.10202@arin.net> References: <4FBB9E33.10202@arin.net> Message-ID: <4FC7D4B8.5040006@arin.net> > The deadline to begin a petition will be five business days after the > AC's draft meeting minutes are published. The minutes from the ARIN Advisory Council's 17 May 2012 meeting have been published: https://www.arin.net/about_us/ac/ac2012_0517.html The deadline to begin a petition for proposal 169 is 7 June 2012. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 5/22/12 10:09 AM, ARIN wrote: > In accordance with the ARIN Policy Development Process, the ARIN > Advisory Council (AC) held a meeting on 17 May 2012 and made decisions > about several draft policies and proposals. > > The AC recommended the following draft policies to the ARIN Board for > adoption: > > ARIN-2012-1: Clarifying requirements for IPv4 transfers > ARIN-2012-3: ASN Transfers > > The following proposals were added to the AC's docket for development > and evaluation: > ARIN-prop-166 Clarify /29 Assignment Identification Requirement > ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers > > The AC considered the following proposal to be an administrative update: > ARIN-prop-169 Cleanup IPv6 section 6.5.7 > > Regarding proposal 169, "The ARIN AC considers the text removal in > this proposal to be administrative, and has asked ARIN staff to work > with the BoT to process this change. The text cited for removal is > from June 26, 2002. The paragraph that will remain was added to to the > September 2011 edition of the NRPM by policy 2011-3. Both pieces of > text accomplish similar goals, however the 2002 text is restrictive to > early /35 assignments. The 2011-3 text is more generic and will cover > any future changes to IPv6 allocation policy." > > The AC has essentially abandoned proposal 169. Anyone dissatisfied > with this decision may initiate a petition. The petition to advance > this proposal would be the "Discussion 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) >